4 ms·

Linear versioning has the baked-in promise that version N is no longer needed because version N+1 is substitutable for it. If that's not true, if apps legitimat

Linear versioning has the baked-in promise that version N is no longer needed because version N+1 is substitutable for it. If that's not true, if apps legitimately depend on specific revisions of the library code (because its authors are not maintaining backwards compatibility), those library builds need different names so they can coexist in the filesystem and dependent apps can name the one they need. There's no reason to treat them as versions of the same package, because switching between them is effectively migrating from one dependency to another (which happens to have many authors in common). > why should it be npm/RuyGems/CPAN/easy_installs/pip's responsibility Because they each have far less work to do than the growing number of spur-of-the-moment integration targets that rpm and dpkg would face. It deters them from requiring features which rpm and dpkg don't have, and which they aren't prepared to implement in a way that every sysadmin everywhere is willing to rely on. And it's they who are creating the problem. > recognize files outside their native database How useful would it be to auto-detect random crap that's been smuggled onto one particular production box behind everyone's backs? You wouldn't know how to uninstall it cleanly, nor what its dependencies currently are (so you could ever safely uninstall anything without potentially breaking it), nor whether it'll be okay to clobber it with a legitimate version from a repository (or what might break if yum let you do it). I'm not that familiar with dpkg, but those are awfully fragile results just to avoid writing an rpmbuild .spec that definitely states these facts and then runs ./configure && make install. -- If I seem like I have a grudge, it's because we spent months digging ourselves out of the hell of "this code is just somehow there on a few of our machines, but we don't know which version it was for which files, how they got there, or how to cleanly deploy a new server that actually works." Unfortunately the pain wasn't borne by the slobs whose negligence got us there over years. That's a drawback to startups—between failures and turnover, too many authors aren't required to work with reckless implementations long enough to learn how bad some ideas really are.

FooBarWidget 16y ago
> If that's not true, if apps legitimately depend on > specific revisions of the library code (because its > authors are not maintaining backwards compatibility), > those library builds need different names so they can > coexist in the filesystem and dependent apps can name > the one they need. Yes that's now RPM/DPKG did it so far, but it's nowhere near as flexible as proper built-in support for multiple versions. What if your app/library depends on exactly version 1.2.3 of libfoobar? What if another app/library depends on all versions >= 1.2.4 and < 1.3.0? You can easily specify that with RubyGems but it's hard to automatically support this in DPKG/RPM. It forces the DPKG/RPM packager to either impose arbitrary restrictions on what versions are packaged (and thus restricting which apps are installable) or to work around it in a stupid way by creating multiple packages, libfoobar1-2-3, libfoobar-1-2-5, libfoobar-2-0-0. If libfoobar 1.2.6 is released the packager has to manually rename libfoobar-1-2-5 to libfoobar-1-2-6 and manually rename the dependency names for packages that depended in foobar >= 1.2.4 && < 1.3.0. This becomes messy and tiresome very quickly. Aren't computers supposed to help humans? > Because they each have far less work to do than the growing number of spur-of-the-moment integration targets that rpm and dpkg would face. It deters them from requiring features which rpm and dpkg don't have, and which they aren't prepared to implement in a way that every sysadmin everywhere is willing to rely on. And it's they who are creating the problem. I don't see how sysadmins would reject proper support for multiple versions. They aren't losing any control over their system or any clarity. > How useful would it be to auto-detect random crap that's been smuggled onto one particular production box behind everyone's backs? Very useful because if those "random crap" exist then that means the sysadmin has knowingly installed them and wants to use them for a reason. You're basically saying "no user, this is what you want but I'm not going to allow it". I can't count the number of times where the user wants to upgrade libxyz to version 2.3.5, but the OS only packages 2.3.4, so the user resorts to installing from source only to find out that RPM/DPKG dependenceis don't like that. The user usually ends up uninstalling all those RPM/DPKG packages and ends up installing those things from source as well.
- prodigal_erik 16y ago
  Gems only works because it's not only a package manager but also a monkey-patch for the Ruby interpreter which decides on the fly which files it should actually load. Nobody's going to be able to do that for every language runtime which has ever existed, so when someone screws up and releases an incompatible change, you have to give the new version's filesystem contents a different name, so dependencies have some way to specify which one they need. At that point it's clearer to rename the package as well. I wouldn't expect any system to be able to make correct dependency checks (is this upgrade or uninstall safe?) for discovered files without being told what the dependencies are. If you have actual sysadmins (not devs who had root by mistake and misused it) who are smuggling files on a production box that aren't owned by a package (even one they created themselves), I hope they'll still be around to suffer the hell they're creating.
  - FooBarWidget 16y ago
    You don't have to do that for every language. Just support multiple versions in DPKG/RPM so that the languages who do support RubyGems-style loading can have multiple versions. Right now converting gems to DPKG/RPM is all manual work with no good way to automate it. DebGem tries to work around it by making a DEB that includes all existing versions but it's far from optimal. > I wouldn't expect any system to be able to make correct dependency checks (is this upgrade or uninstall safe?) for discovered files without being told what the dependencies are. So... tell it what the dependencies are? Autoconf configure scripts can check for arbitrary things. It's just package managers that insist on only listening to their own databases.

FooBarWidget 16y ago

> If that's not true, if apps legitimately depend on > specific revisions of the library code (because its > authors are not maintaining backwards compatibility), > those library builds need different names so they can > coexist in the filesystem and dependent apps can name > the one they need. Yes that's now RPM/DPKG did it so far, but it's nowhere near as flexible as proper built-in support for multiple versions. What if your app/library depends on exactly version 1.2.3 of libfoobar? What if another app/library depends on all versions >= 1.2.4 and < 1.3.0? You can easily specify that with RubyGems but it's hard to automatically support this in DPKG/RPM. It forces the DPKG/RPM packager to either impose arbitrary restrictions on what versions are packaged (and thus restricting which apps are installable) or to work around it in a stupid way by creating multiple packages, libfoobar1-2-3, libfoobar-1-2-5, libfoobar-2-0-0. If libfoobar 1.2.6 is released the packager has to manually rename libfoobar-1-2-5 to libfoobar-1-2-6 and manually rename the dependency names for packages that depended in foobar >= 1.2.4 && < 1.3.0. This becomes messy and tiresome very quickly. Aren't computers supposed to help humans? > Because they each have far less work to do than the growing number of spur-of-the-moment integration targets that rpm and dpkg would face. It deters them from requiring features which rpm and dpkg don't have, and which they aren't prepared to implement in a way that every sysadmin everywhere is willing to rely on. And it's they who are creating the problem. I don't see how sysadmins would reject proper support for multiple versions. They aren't losing any control over their system or any clarity. > How useful would it be to auto-detect random crap that's been smuggled onto one particular production box behind everyone's backs? Very useful because if those "random crap" exist then that means the sysadmin has knowingly installed them and wants to use them for a reason. You're basically saying "no user, this is what you want but I'm not going to allow it". I can't count the number of times where the user wants to upgrade libxyz to version 2.3.5, but the OS only packages 2.3.4, so the user resorts to installing from source only to find out that RPM/DPKG dependenceis don't like that. The user usually ends up uninstalling all those RPM/DPKG packages and ends up installing those things from source as well.

prodigal_erik 16y ago
Gems only works because it's not only a package manager but also a monkey-patch for the Ruby interpreter which decides on the fly which files it should actually load. Nobody's going to be able to do that for every language runtime which has ever existed, so when someone screws up and releases an incompatible change, you have to give the new version's filesystem contents a different name, so dependencies have some way to specify which one they need. At that point it's clearer to rename the package as well. I wouldn't expect any system to be able to make correct dependency checks (is this upgrade or uninstall safe?) for discovered files without being told what the dependencies are. If you have actual sysadmins (not devs who had root by mistake and misused it) who are smuggling files on a production box that aren't owned by a package (even one they created themselves), I hope they'll still be around to suffer the hell they're creating.
- FooBarWidget 16y ago
  You don't have to do that for every language. Just support multiple versions in DPKG/RPM so that the languages who do support RubyGems-style loading can have multiple versions. Right now converting gems to DPKG/RPM is all manual work with no good way to automate it. DebGem tries to work around it by making a DEB that includes all existing versions but it's far from optimal. > I wouldn't expect any system to be able to make correct dependency checks (is this upgrade or uninstall safe?) for discovered files without being told what the dependencies are. So... tell it what the dependencies are? Autoconf configure scripts can check for arbitrary things. It's just package managers that insist on only listening to their own databases.