Maintainers Matter: The case against upstream packaging
1–10 of 96 posts
Re: Maintainers Matter: The case against upstream packaging
#2Re: Maintainers Matter: The case against upstream packaging
#3I agree with a lot of this. GNU/Linux distros are going down a very dangerous path with Snappy, Docker, Flatpak, Atomic, etc. I think a lot of this is responding to the fact that traditional systems package managers are quite bad by today's standards. They are imperative (no atomic transactions), use global state (/usr), and require root privileges. Snappy and co. take the "fuck it, I'm out" approach of bundling the world with your application, which is terrible for user control and security. Instead, I urge folks to check out the functional package managers GNU Guix[0] and Nix[1], and their accompanying distributions GuixSD and NixOS. Both Guix and Nix solve the problems of traditional systems package managers, while adding additional useful features (like reproducible builds, universal virtualenv, and full-system config management) and avoiding the massive drawbacks of Snappy and friends.
Re: Maintainers Matter: The case against upstream packaging
#4That's really good case about upstream packaging. Do we really want yet another android story? I trust maintainer which is volunteering it's time to ensure the package complies with distributions guidelines.
With universal packages we would have universal config file paths. So for example: apache2 on debian based systems will store documents on /var/www while something like arch will store them at /srv/httpd. Similar thing happens with a `sites-available` accross distros. Different distributions are doing things differently, which users are expecting and putting upstream developers in charge of that will make a huge mess, because it's more convenient for them to store configuration at a specific location accross every distribution. Yes that makes a pain to write deployment scripts accross difrerent distros, but IMO consistensy is a key to a good distribution.
Another good key point here would be testing, different distributions aim for different things, while debian aims for maximum stability and uses quite dated packages that are known to work. Where there are distributions which are always on the bleeding edge. Will upstream backport security patches for old packages? I really doubt they would like to maintain packages for years to come.
I don't say it would be all bad, there certainly would be great developers which would benefit from universal packaging, but that will not always be the case.
Re: Maintainers Matter: The case against upstream packaging
#5This seems like an overly optimistic view of the abilities and resources of distribution package maintainers. The reality is that no matter how hard they try, it's almost impossible for them to keep up, and even with a non-LTS Ubuntu release train I still need to use a number of PPAs and other mechanisms of install to get some things I use on a daily basis.
And that's with both Canonical and Debian's resources involved in making sure that I get a relatively up to date base set of packages.
Never mind the issue of when your politics don't quite align with any distribution maintainer's in the whole.
(Note: edited to clarify 'bleeding edge ubuntu' as meaning the non-LTS release train)
Re: Maintainers Matter: The case against upstream packaging
#6Enough of this. People have the right to install last version of software easily without having to upgrade the whole server at once. ISV have the right to package their own software.
If MongoDB is a commodity I can gladly stick to the distro version. If I'm developing something of more cutting edge I want and will install the latest version from the ISV repo.
Re: Maintainers Matter: The case against upstream packaging
#7Enough of this. People have the right to install last version of software easily without having to upgrade the whole server at once. ISV have the right to package their own software. If MongoDB is a commodity I can gladly stick to the distro version. If I'm developing something of more cutting edge I want and will install the latest version from the ISV repo.
Yes they can, there is nothing preventing them creating the package. But it shouldn't be a primary way of installing package. If you really need bleeding edge for development you can build it yourself.
Re: Maintainers Matter: The case against upstream packaging
#8In other news: https://www.nginx.com/blog/supporting-http2-google-chrome-us...
Note: It may be worth providing a bit more info about why you are linking the article. It's a relevant example of the counterpoint playing out in real-time, which people may miss from the simple preface "In other news:"
To ensure the operating system is stable and reliable, OS distributors do not make major updates to packages such as OpenSSL during the lifetime of each release.
Not entirely true. RHEL backports bug and security fixes continuously, and select feature enhancements are rolled out with point releases. For example, RHEL 7.2 updated mod_nss, and enabled TLS v1.1 and v1.2 in NSS (I'm not sure how that interacts with Nginx, if at all). I imagine RHEL 7.3 should be coming out any time now. Maybe it will help with this.
1: https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...
Re: Maintainers Matter: The case against upstream packaging
#9Enough of this. People have the right to install last version of software easily without having to upgrade the whole server at once. ISV have the right to package their own software. If MongoDB is a commodity I can gladly stick to the distro version. If I'm developing something of more cutting edge I want and will install the latest version from the ISV repo.
Yes they can, there is nothing preventing them creating the package. But it shouldn't be a primary way of installing package. If you really need bleeding edge for development you can build it yourself.
I'll just let my ISV do that for me, thank you.
Re: Maintainers Matter: The case against upstream packaging
#10Enough of this. People have the right to install last version of software easily without having to upgrade the whole server at once. ISV have the right to package their own software. If MongoDB is a commodity I can gladly stick to the distro version. If I'm developing something of more cutting edge I want and will install the latest version from the ISV repo.
Yes they can, there is nothing preventing them creating the package. But it shouldn't be a primary way of installing package. If you really need bleeding edge for development you can build it yourself.
This type of attitude completely ignores regular desktop users who may one day want to use Linux over Windows.