5 ms·

And then they get yelled at by upstream for not including the latest and "greatest"...

scrollaway 9y ago
Yeah, well, rightfully so. I used to love Debian and I've grown more and more disillusioned by it. Their main problem is two fold: 1) They mess with the packages they distribute. Like, a lot, rather than trust upstream. And 2) they don't update things that seriously need to get updated. Example 1: Using System Python on Debian is a notoriously terrible experience for example, because they split up the venv module from Python itself and distribute it separately. I've had so many issues because of that and there's no good reason to do it. It's part of the stdlib, it doesn't need a separate package. Example 2: Debian Jessie shipped with the ancient pip 1.5.6 (https://packages.debian.org/jessie/python-pip https://packages.debian.org/jessie/python-pip - upstream is at 9.0.1 since 2016) which never got updated, just stayed stuck there, wtf? Such old versions of pip are lacking support for a bunch of things that python packages today use on setup, so it would install things in a weird way and then packages would be broken, users wouldn't understand why. One of the many cases of not giving users access to a more recent version of a package, causing the user's experience to be severely impacted (and of course, they won't know to blame debian or the pip version in this case). Edit: Incidentally, that last bit is why I always, always do `pip install --upgrade pip wheel setuptools` whenever I create a new virtual environment to make sure I don't get issues installing packages.
- vbernat 9y ago
  I don't know the story behind the separate venv package (and can't imagine why this is a separate package). pip relies on bundled libraries and tries hard to fight any unbundling (by using slightly patched versions of the dependencies if I remember correctly). This makes it difficult to package. You can see as an additional proof of Debian messing with packages while on the Debian side, this is just the application of a distro-wide policy. If every piece of software should get an exception to the rule, we don't have a distribution anymore.
  - digi_owl 9y ago
    > If every piece of software should get an exception to the rule, we don't have a distribution anymore. And from what i can tell, quite a bit of upstream would see that as a good thing. They just want to stuff their thing into a container and call it a day, distros be damned. To me that is like going back to the DOS days of software, or even close to the present day of Windows software, where everything is dangling off in their own sub-dir with all their snowflake variants of dependencies. Damn it, go back a few years and Microsoft go burned by this when they discovered that there was a vulnerability in the VC++ redistributable dlls. All they could do was issue updates for their own software, a tool for scanning the drive for vulnerable copies of the dlls, and a wish that customers would badger their software providers for updated versions of affected software.
- tetraodonpuffer 9y ago
  I honestly think it is a good idea, no matter which distribution or OS you are on, to never ever depend on system python/pip (or perl for that matter), just install pyenv / pipenv / pipsi (or perlbrew) so you have complete control. From a distribution perspective I sometimes wonder if it wouldn't be a better idea to call the system python/perl something like system-python/system-perl to make it more obvious they are not meant for use, and have a /usr/bin/python that tells you to install pyenv...
- ris 9y ago
  > 1) They mess with the packages they distribute. Like, a lot, rather than trust upstream Having had quite a lot of experience of both, what I call, maintained packages and wild west packages (e.g. pypi), I would trust the former over the latter any day of the week. Developers generally do not make tremendously good maintainers. They tend to to only really care about the latest versions of anything, don't take particular care to make sure their package works well with other packages, rarely backport security fixes, and frequently do everything in a unilateral way. (I've seen it all, subtly different tarballs uploaded under the same version number, old releases deleted, breaking changes released under minor version bumps, addition of user-hostile "features", downloading & installing unexpected random binaries from the internet in attempt to make everything "just work", and of course they're forever bundling odd versions of other packages which they then don't maintain...) Maintainers working on a "distribution" have a responsibility to make the whole distribution of software work well & stably together, and they generally do so quite well with the odd slip up (I'm looking in the direction of the debian-openssl screwup). These days I tend to use a debian base system with Nix on top of it for when I need specific, repeatable or more recent versions of something.
  - jancsika 9y ago
    > Maintainers working on a "distribution" have a responsibility to make the whole distribution of software work well & stably together, and they generally do so quite well with the odd slip up (I'm looking in the direction of the debian-openssl screwup). Is there a policy that requires Debian package maintainers to seek mentorship of upstream when patching core packages? I understand your point about maintained packages. But it's only a significant advantage if the maintainer's decisions must be filtered through the lens of the software maintainers. Otherwise one must trade the narrow expertise of the software maintainer for the wider expertise of the package maintainer. That doesn't seem like a wise tradeoff IMO, and I don't see how a future openssl debacle could be prevented otherwise.
  - willtim 9y ago
    Having package maintainers touch any code, even to backport security fixes, is far from ideal. In 2006, a big security flaw was introduced into Debian's OpenSSL by the maintainer, because he changed code that he did not fully understand. The flaw wasn't discovered until 2008: https://www.schneier.com/blog/archives/2008/05/random_number_b.html https://www.schneier.com/blog/archives/2008/05/random_number...
- jlarocco 9y ago
  I don't mind that Debian will patch upstream packages to make them fit better with the overall Debian system. If I wanted a no frills system, with minimal integration, that strictly followed upstream for everything, then I'd move back to Slackware. Their policy on language specific package management is also pretty reasonable. There's no point duplicating effort packaging things in both Pip and the Debian repos when those package managers work fine under Debian. It lets Python devs use the same tools as every other Python developer on other systems, and avoids Debian specific instructions for package installation. It also completely side steps the problem of following upstream for all of those packages. The advice I've always followed is to always use the language specific package management unless I'm specifically building a package for Debian.
- bharrison 9y ago
  >X2... The author of xscreensaver became so upset by similar circumstances that he threw down a gauntlet; ship the ancient package with an updated splash screen warning users of how old it is, or stop shipping it. https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/ https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop...
  - digi_owl 9y ago
    The real problem there was that Debian left the splash screen in place, complete with the email of the author. Thus people would contact him directly rather than Debian when an issue was noticed. Then again JWZ is quite the character...

Yeah, well, rightfully so. I used to love Debian and I've grown more and more disillusioned by it. Their main problem is two fold: 1) They mess with the packages they distribute. Like, a lot, rather than trust upstream. And 2) they don't update things that seriously need to get updated. Example 1: Using System Python on Debian is a notoriously terrible experience for example, because they split up the venv module from Python itself and distribute it separately. I've had so many issues because of that and there's no good reason to do it. It's part of the stdlib, it doesn't need a separate package. Example 2: Debian Jessie shipped with the ancient pip 1.5.6 (https://packages.debian.org/jessie/python-pip https://packages.debian.org/jessie/python-pip - upstream is at 9.0.1 since 2016) which never got updated, just stayed stuck there, wtf? Such old versions of pip are lacking support for a bunch of things that python packages today use on setup, so it would install things in a weird way and then packages would be broken, users wouldn't understand why. One of the many cases of not giving users access to a more recent version of a package, causing the user's experience to be severely impacted (and of course, they won't know to blame debian or the pip version in this case). Edit: Incidentally, that last bit is why I always, always do `pip install --upgrade pip wheel setuptools` whenever I create a new virtual environment to make sure I don't get issues installing packages.

vbernat 9y ago
I don't know the story behind the separate venv package (and can't imagine why this is a separate package). pip relies on bundled libraries and tries hard to fight any unbundling (by using slightly patched versions of the dependencies if I remember correctly). This makes it difficult to package. You can see as an additional proof of Debian messing with packages while on the Debian side, this is just the application of a distro-wide policy. If every piece of software should get an exception to the rule, we don't have a distribution anymore.
- digi_owl 9y ago
  > If every piece of software should get an exception to the rule, we don't have a distribution anymore. And from what i can tell, quite a bit of upstream would see that as a good thing. They just want to stuff their thing into a container and call it a day, distros be damned. To me that is like going back to the DOS days of software, or even close to the present day of Windows software, where everything is dangling off in their own sub-dir with all their snowflake variants of dependencies. Damn it, go back a few years and Microsoft go burned by this when they discovered that there was a vulnerability in the VC++ redistributable dlls. All they could do was issue updates for their own software, a tool for scanning the drive for vulnerable copies of the dlls, and a wish that customers would badger their software providers for updated versions of affected software.
tetraodonpuffer 9y ago
I honestly think it is a good idea, no matter which distribution or OS you are on, to never ever depend on system python/pip (or perl for that matter), just install pyenv / pipenv / pipsi (or perlbrew) so you have complete control. From a distribution perspective I sometimes wonder if it wouldn't be a better idea to call the system python/perl something like system-python/system-perl to make it more obvious they are not meant for use, and have a /usr/bin/python that tells you to install pyenv...
ris 9y ago
> 1) They mess with the packages they distribute. Like, a lot, rather than trust upstream Having had quite a lot of experience of both, what I call, maintained packages and wild west packages (e.g. pypi), I would trust the former over the latter any day of the week. Developers generally do not make tremendously good maintainers. They tend to to only really care about the latest versions of anything, don't take particular care to make sure their package works well with other packages, rarely backport security fixes, and frequently do everything in a unilateral way. (I've seen it all, subtly different tarballs uploaded under the same version number, old releases deleted, breaking changes released under minor version bumps, addition of user-hostile "features", downloading & installing unexpected random binaries from the internet in attempt to make everything "just work", and of course they're forever bundling odd versions of other packages which they then don't maintain...) Maintainers working on a "distribution" have a responsibility to make the whole distribution of software work well & stably together, and they generally do so quite well with the odd slip up (I'm looking in the direction of the debian-openssl screwup). These days I tend to use a debian base system with Nix on top of it for when I need specific, repeatable or more recent versions of something.
- jancsika 9y ago
  > Maintainers working on a "distribution" have a responsibility to make the whole distribution of software work well & stably together, and they generally do so quite well with the odd slip up (I'm looking in the direction of the debian-openssl screwup). Is there a policy that requires Debian package maintainers to seek mentorship of upstream when patching core packages? I understand your point about maintained packages. But it's only a significant advantage if the maintainer's decisions must be filtered through the lens of the software maintainers. Otherwise one must trade the narrow expertise of the software maintainer for the wider expertise of the package maintainer. That doesn't seem like a wise tradeoff IMO, and I don't see how a future openssl debacle could be prevented otherwise.
- willtim 9y ago
  Having package maintainers touch any code, even to backport security fixes, is far from ideal. In 2006, a big security flaw was introduced into Debian's OpenSSL by the maintainer, because he changed code that he did not fully understand. The flaw wasn't discovered until 2008: https://www.schneier.com/blog/archives/2008/05/random_number_b.html https://www.schneier.com/blog/archives/2008/05/random_number...
jlarocco 9y ago
I don't mind that Debian will patch upstream packages to make them fit better with the overall Debian system. If I wanted a no frills system, with minimal integration, that strictly followed upstream for everything, then I'd move back to Slackware. Their policy on language specific package management is also pretty reasonable. There's no point duplicating effort packaging things in both Pip and the Debian repos when those package managers work fine under Debian. It lets Python devs use the same tools as every other Python developer on other systems, and avoids Debian specific instructions for package installation. It also completely side steps the problem of following upstream for all of those packages. The advice I've always followed is to always use the language specific package management unless I'm specifically building a package for Debian.
bharrison 9y ago
>X2... The author of xscreensaver became so upset by similar circumstances that he threw down a gauntlet; ship the ancient package with an updated splash screen warning users of how old it is, or stop shipping it. https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/ https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop...
- digi_owl 9y ago
  The real problem there was that Debian left the splash screen in place, complete with the email of the author. Thus people would contact him directly rather than Debian when an issue was noticed. Then again JWZ is quite the character...