3 ms·

>Windows and Mac don't have dependency management at all. Not sure why you feel so compelled to talk about OSs I didn't mention. I was talking about the iOS Ap

by ksk 13y ago

>Windows and Mac don't have dependency management at all. Not sure why you feel so compelled to talk about OSs I didn't mention. I was talking about the iOS App Store. In any case - apt-get, yum etc are third party tools that just copy, extract files from some server and run some pre-made configuration scripts. Thats all they do. All the hard work of figuring out dependencies, avoiding cycles, etc is done OUTSIDE the OS by the repository maintainers. You can do that on ANY OS. >The thing about different repos with the same deps is solved with 'priorities', since its inception. Different repositories which the user ads can and do have dependency conflicts. One package from repo-1 can require a lib with version >= 1.0 while another package from another repo-2 will only work with version 0.9, etc. I have often had to add add other repos to get software unavailable in current repos. I have run in to these issues quite often. And I am not even getting into how brittle apt-get in general is.

rantanplan 13y ago
>Not sure why you feel so compelled to talk about OSs I didn't mention. Because you said:"Linux, unlike a modern OS, lacks any kind of sane dependency management", which is of course non-sensical, as it is the only OS with dependency management. Also in the case of RPM the dependencies are listed inside the package, the YUM then just does the dependency resolution and fetches the required packages. I really don't understand what point you're trying reach, since automatic dependency management/resolving is one of the most important reasons Linux is chosen for server environments and deployments. Since I've been doing this for a living for more than 10 years, I really don't know how you have found so many problems and issues with it. Maybe you're using some kind of rolling-release distro? And of course nope; you can't do that on any OS, because.... we would have done it! That's why homebrew for Mac feels like a poor man's apt/yum system.
- ksk 13y ago
  > I really don't understand what point you're trying reach, since automatic dependency management/resolving is one of the most important reasons Linux is chosen for server environments and deployments. >Since I've been doing this for a living for more than 10 years, I really don't know how you have found so many problems and issues with it. Maybe you're using some kind of rolling-release distro? For average desktop users things like third party repos, PPAs, etc induce failure modes in apt-get that are quite common. One of the most common ways that users get screwed is by adding too many third party repositories or steping outside the repository and build/install via source or installing an rpm/deb file manually. The main reason is the OS does not handle dependencies, only the package manager does. So if you step outside the package manager.. you can get burnt fairly easily doing benign things. A few examples I found in under a minute... http://unix.stackexchange.com/questions/43952/ http://unix.stackexchange.com/questions/43952/ http://unix.stackexchange.com/questions/5505/ http://unix.stackexchange.com/questions/5505/ http://unix.stackexchange.com/questions/59930/ http://unix.stackexchange.com/questions/59930/ http://unix.stackexchange.com/questions/96282 http://unix.stackexchange.com/questions/96282 http://unix.stackexchange.com/questions/8963/ http://unix.stackexchange.com/questions/8963/ >because.... we would have done it! That's why homebrew for Mac feels like a poor man's apt/yum system. That's rather poor reasoning. There are several factors why one would not want to maintain a giant repository of packages and associated dependencies. For one, atleast on newer OSX installs the presence of the Mac App Store negates any large scale interest in such a project. Also the fact that tech like macports, chocolatey, nuget, etc exist, demonstrates the proof of concept. Also I'd like to stick my neck out a bit for MS tech like AppV which is the underlying tech for MS Office 2013 IIRC which allows centralized deployment for enterprises. Its better than apt-get IMHO. Across platforms I'd say Steam is a much more better platform than apt-get/yum etc for digital distribution of software. On Windows - the only dependencies would be third party libs like PhysX, OpenAL, etc. Windows, since XP, has a great OS-level dependency solution (unlike apt-get and the rest - which the Linux kernel/executable loader/etc do not know about explicitly) for installing multiple versions of libraries side by side and having the developer specify things like - whether they want the latest version or whether they want a specific version, etc via simple application manifests.
  - rantanplan 13y ago
    Look, no offence, but by the look of the links you gave, you have no leg to stand on and you seem to conflate package management and resolution with software distribution platforms(which has more to do with marketing than technology). All the links you provided have one of the following traits: 1) User decided to build from source - That's outside the package management and FYI "make && make install" on Linux is exactly the same on Mac. 2) User decided to include Testing repositories on Debian which, since you don't know, it's like having a different Debian distro. 3) User decided to install broken proprietary software(in that case Oracle) that for arbitrary reasons forced the user to install x86 packages while the user's system is 64-bit. In any case, you don't install Debian if you want bleeding edge packages - wrong tool for the job. Choose Fedora, Ubuntu or OpenSUSE. If you work in the CS industry and you say that no one wants something like Linux package management, well you simply... don't work in the industry. AppStore, Steam and whatnot have absolutely nothing to do with package management and dep resolution. Also try something, make a script or program that installs and deploys automatically a development environment with either of the aforementioned technologies. Oh you can't? Yeah that's because you conflate technology issues with marketing issues.
    - ksk 13y ago
      >1) User decided to build from source - That's outside the package management and FYI "make && make install" on Linux is exactly the same on Mac. So Linux as an OS does not do dependency management - you have to stay within a third party tool/package manager. Thanks for proving my point. 2) User decided to include Testing repositories on Debian which, since you don't know, it's like having a different Debian distro. Adding more repos leads to breakage - Exactly what I said. You are adding nothing new. 3) User decided to install broken proprietary software(in that case Oracle) that for arbitrary reasons forced the user to install x86 packages while the user's system is 64-bit. It would have made no difference if it wasn't proprietary. Also I have seen such breaks multiple times with F/OSS software. >If you work in the CS industry and you say that no one wants something like Linux package management, well you simply... don't work in the industry. Stop putting words in other peoples mouths. Thats dishonest. >AppStore, Steam and whatnot have absolutely nothing to do with package management and dep resolution. Good job replying to something I never said. My mention of Steam and the App store was specifically for digital distribution. Heck .. I even said so myself... Let me quote myself.. (rather sad that I have to do this) "The Apple App Store distributes _self contained_ binaries+dependencies (excluding OS libs) which is one sane way of doing things." "Across platforms I'd say Steam is a much more better platform than apt-get/yum etc for digital distribution of software." This is my last reply. Goodbye.
nly 13y ago
> All the hard work of figuring out dependencies, avoiding cycles, etc is done OUTSIDE the OS by the repository maintainers Your typical package manager will build a recursive and reverse dependency database, resolve version conflicts, detect cycles, and suggest alternative dependencies and recommended or optional packages. Here's the official PKGBUILD used by Arch for ffmpeg as an example. There's not a single version qualifier in sight, and no other files are needed to build and install the package... from source. https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/ffmpeg https://projects.archlinux.org/svntogit/packages.git/tree/tr... It's not exactly trivial, but FOSS OSs have been doing this for decades and have hundreds of thousands of packages. It's a vast improvement over having 28 copies of the openssl dll on your average Windows machine, all out of date.
- ksk 13y ago
  >Your typical package manager will build a recursive and reverse dependency database, resolve version conflicts, detect cycles, and suggest alternative dependencies and recommended or optional packages. All that is done outside the OS by third party code. Also, you have to stay within that particular package manager to get those benefits. With different distros you have to stay within whatever package manager they ship with. There is no common "linux" code that allows this to happen (Indeed you can implement a package manager on any OS). If you go around installing rpms manually or installing/building via source, it is fairly trivial to bork your package managers state. For e.g. - If you manually build/install a dependency that one particular package in the repo says should be of a different version..
  - nly 13y ago
    The package manager is part of the OS distribution. It's not 3rd party code.
    - ksk 13y ago
      Unless its LFS. :) But yes, in general all mainstream Linux distros do ship with many tools/libs - X.org, GTK, Gnome, whatnot. Are all of them part of the OS? I see the package manager as a third party tool much like the rest since it does not interact with the core OS in any deep sense. But maybe my point of view comes from being a Linux user since 1996 with Slackware..
code_duck 13y ago
>In any case - apt-get, yum etc are third party tools that just copy, extract files from some server and run some pre-made configuration scripts. Thats all they do. Third party to whom, exactly? Each major distribution maintains its own repositories and packaging system. Okay, so that's all they do... it works great. They also provide a central place for your system to download a huge variety of software that has been tested and approved for your specific OS version. >All the hard work of figuring out dependencies, avoiding cycles, etc is done OUTSIDE the OS by the repository maintainers. You can do that on ANY OS. You could, but they don't. The fact is that for years prior to the Apple App Store for iPhone or OSX, or the Windows Store, there existed a way to install a wide variety of Linux software automatically and easily from a central source. >Different repositories which the user ads can and do have dependency conflicts. One package from repo-1 can require a lib with version >= 1.0 while another package from another repo-2 will only work with version 0.9, etc. I have often had to add add other repos to get software unavailable in current repos. I have run in to these issues quite often. And I am not even getting into how brittle apt-get in general is. Sure, that's true. Personally I've always found the software I need on the main repositories for Ubuntu or Debian, and not needed to add external sources. When there is a package I need that's not in a repository, installing a binary or compiling from source has worked fine. So I haven't experienced the problems you mention or hint at in 10-12 years of desktop and server Linux use.

by ksk 13y ago

rantanplan 13y ago

>Not sure why you feel so compelled to talk about OSs I didn't mention. Because you said:"Linux, unlike a modern OS, lacks any kind of sane dependency management", which is of course non-sensical, as it is the only OS with dependency management. Also in the case of RPM the dependencies are listed inside the package, the YUM then just does the dependency resolution and fetches the required packages. I really don't understand what point you're trying reach, since automatic dependency management/resolving is one of the most important reasons Linux is chosen for server environments and deployments. Since I've been doing this for a living for more than 10 years, I really don't know how you have found so many problems and issues with it. Maybe you're using some kind of rolling-release distro? And of course nope; you can't do that on any OS, because.... we would have done it! That's why homebrew for Mac feels like a poor man's apt/yum system.

ksk 13y ago
> I really don't understand what point you're trying reach, since automatic dependency management/resolving is one of the most important reasons Linux is chosen for server environments and deployments. >Since I've been doing this for a living for more than 10 years, I really don't know how you have found so many problems and issues with it. Maybe you're using some kind of rolling-release distro? For average desktop users things like third party repos, PPAs, etc induce failure modes in apt-get that are quite common. One of the most common ways that users get screwed is by adding too many third party repositories or steping outside the repository and build/install via source or installing an rpm/deb file manually. The main reason is the OS does not handle dependencies, only the package manager does. So if you step outside the package manager.. you can get burnt fairly easily doing benign things. A few examples I found in under a minute... http://unix.stackexchange.com/questions/43952/ http://unix.stackexchange.com/questions/43952/ http://unix.stackexchange.com/questions/5505/ http://unix.stackexchange.com/questions/5505/ http://unix.stackexchange.com/questions/59930/ http://unix.stackexchange.com/questions/59930/ http://unix.stackexchange.com/questions/96282 http://unix.stackexchange.com/questions/96282 http://unix.stackexchange.com/questions/8963/ http://unix.stackexchange.com/questions/8963/ >because.... we would have done it! That's why homebrew for Mac feels like a poor man's apt/yum system. That's rather poor reasoning. There are several factors why one would not want to maintain a giant repository of packages and associated dependencies. For one, atleast on newer OSX installs the presence of the Mac App Store negates any large scale interest in such a project. Also the fact that tech like macports, chocolatey, nuget, etc exist, demonstrates the proof of concept. Also I'd like to stick my neck out a bit for MS tech like AppV which is the underlying tech for MS Office 2013 IIRC which allows centralized deployment for enterprises. Its better than apt-get IMHO. Across platforms I'd say Steam is a much more better platform than apt-get/yum etc for digital distribution of software. On Windows - the only dependencies would be third party libs like PhysX, OpenAL, etc. Windows, since XP, has a great OS-level dependency solution (unlike apt-get and the rest - which the Linux kernel/executable loader/etc do not know about explicitly) for installing multiple versions of libraries side by side and having the developer specify things like - whether they want the latest version or whether they want a specific version, etc via simple application manifests.
- rantanplan 13y ago
  Look, no offence, but by the look of the links you gave, you have no leg to stand on and you seem to conflate package management and resolution with software distribution platforms(which has more to do with marketing than technology). All the links you provided have one of the following traits: 1) User decided to build from source - That's outside the package management and FYI "make && make install" on Linux is exactly the same on Mac. 2) User decided to include Testing repositories on Debian which, since you don't know, it's like having a different Debian distro. 3) User decided to install broken proprietary software(in that case Oracle) that for arbitrary reasons forced the user to install x86 packages while the user's system is 64-bit. In any case, you don't install Debian if you want bleeding edge packages - wrong tool for the job. Choose Fedora, Ubuntu or OpenSUSE. If you work in the CS industry and you say that no one wants something like Linux package management, well you simply... don't work in the industry. AppStore, Steam and whatnot have absolutely nothing to do with package management and dep resolution. Also try something, make a script or program that installs and deploys automatically a development environment with either of the aforementioned technologies. Oh you can't? Yeah that's because you conflate technology issues with marketing issues.
  - ksk 13y ago
    >1) User decided to build from source - That's outside the package management and FYI "make && make install" on Linux is exactly the same on Mac. So Linux as an OS does not do dependency management - you have to stay within a third party tool/package manager. Thanks for proving my point. 2) User decided to include Testing repositories on Debian which, since you don't know, it's like having a different Debian distro. Adding more repos leads to breakage - Exactly what I said. You are adding nothing new. 3) User decided to install broken proprietary software(in that case Oracle) that for arbitrary reasons forced the user to install x86 packages while the user's system is 64-bit. It would have made no difference if it wasn't proprietary. Also I have seen such breaks multiple times with F/OSS software. >If you work in the CS industry and you say that no one wants something like Linux package management, well you simply... don't work in the industry. Stop putting words in other peoples mouths. Thats dishonest. >AppStore, Steam and whatnot have absolutely nothing to do with package management and dep resolution. Good job replying to something I never said. My mention of Steam and the App store was specifically for digital distribution. Heck .. I even said so myself... Let me quote myself.. (rather sad that I have to do this) "The Apple App Store distributes _self contained_ binaries+dependencies (excluding OS libs) which is one sane way of doing things." "Across platforms I'd say Steam is a much more better platform than apt-get/yum etc for digital distribution of software." This is my last reply. Goodbye.

nly 13y ago

> All the hard work of figuring out dependencies, avoiding cycles, etc is done OUTSIDE the OS by the repository maintainers Your typical package manager will build a recursive and reverse dependency database, resolve version conflicts, detect cycles, and suggest alternative dependencies and recommended or optional packages. Here's the official PKGBUILD used by Arch for ffmpeg as an example. There's not a single version qualifier in sight, and no other files are needed to build and install the package... from source. https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/ffmpeg https://projects.archlinux.org/svntogit/packages.git/tree/tr... It's not exactly trivial, but FOSS OSs have been doing this for decades and have hundreds of thousands of packages. It's a vast improvement over having 28 copies of the openssl dll on your average Windows machine, all out of date.

ksk 13y ago
>Your typical package manager will build a recursive and reverse dependency database, resolve version conflicts, detect cycles, and suggest alternative dependencies and recommended or optional packages. All that is done outside the OS by third party code. Also, you have to stay within that particular package manager to get those benefits. With different distros you have to stay within whatever package manager they ship with. There is no common "linux" code that allows this to happen (Indeed you can implement a package manager on any OS). If you go around installing rpms manually or installing/building via source, it is fairly trivial to bork your package managers state. For e.g. - If you manually build/install a dependency that one particular package in the repo says should be of a different version..
- nly 13y ago
  The package manager is part of the OS distribution. It's not 3rd party code.
  - ksk 13y ago
    Unless its LFS. :) But yes, in general all mainstream Linux distros do ship with many tools/libs - X.org, GTK, Gnome, whatnot. Are all of them part of the OS? I see the package manager as a third party tool much like the rest since it does not interact with the core OS in any deep sense. But maybe my point of view comes from being a Linux user since 1996 with Slackware..

code_duck 13y ago

>In any case - apt-get, yum etc are third party tools that just copy, extract files from some server and run some pre-made configuration scripts. Thats all they do. Third party to whom, exactly? Each major distribution maintains its own repositories and packaging system. Okay, so that's all they do... it works great. They also provide a central place for your system to download a huge variety of software that has been tested and approved for your specific OS version. >All the hard work of figuring out dependencies, avoiding cycles, etc is done OUTSIDE the OS by the repository maintainers. You can do that on ANY OS. You could, but they don't. The fact is that for years prior to the Apple App Store for iPhone or OSX, or the Windows Store, there existed a way to install a wide variety of Linux software automatically and easily from a central source. >Different repositories which the user ads can and do have dependency conflicts. One package from repo-1 can require a lib with version >= 1.0 while another package from another repo-2 will only work with version 0.9, etc. I have often had to add add other repos to get software unavailable in current repos. I have run in to these issues quite often. And I am not even getting into how brittle apt-get in general is. Sure, that's true. Personally I've always found the software I need on the main repositories for Ubuntu or Debian, and not needed to add external sources. When there is a package I need that's not in a repository, installing a binary or compiling from source has worked fine. So I haven't experienced the problems you mention or hint at in 10-12 years of desktop and server Linux use.