Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maintainers Matter: The case against upstream packaging

kmkeen.com

Post reply on HN
Print view View original

31–40 of 96 posts

Re: Maintainers Matter: The case against upstream packaging

#31

Post by yenda »

davexunit wrote: post #3

I 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…

I started reading your comment and around the 3rd line I already knew it was you without looking at your nick :D I am thinking about going back to Guix soon, this was an awesome experience for me even though the philosophy was a bit too "free" for my hardware.

Re: Maintainers Matter: The case against upstream packaging

#32

Post by gkya »

stormbrew wrote: post #20
gkya wrote: post #14

Earlier quoted context omitted.

When you serve out an entire system for a group of diverse users with lots of installable programs, it's important to ensure that parts will work together. Especially in Unix where namespace clashes in /bin, /lib and /etc may cause serious problem for system administrators and users. Thus, every stable release has to ensure that none of provided software shall do nothing nasty. But with bleeding edge, you lose the co…

I didn't say I want an entirely bleeding edge system. I said a bleeding edge ubuntu, by which I mean keeping up to date on the non-LTS track (I updated my original post to say that, because I can see where the confusion lies here). Out of the 2500 or so packages installed on the computer I'm typing this on, I want about 10 of them to be bleeding edge. Maybe 20.

So isn't having a separate channel for those 20 that change and update often but thus more prone to risk than the other 2480 packages that you probably would like to work and not bother you a good thing for your productivity and security? Now I last used ubuntu 2-3 years ago and IDK a lot about PPAs, but, what are the shortcomings, exactly? Clashing dependencies (i.e. sth. in your ppa wants libbob 2.0, but ubuntu has 1.8)? The packages you want don't have PPAs?

Re: Maintainers Matter: The case against upstream packaging

#33

Post by gkya »

rodgerd wrote: post #16
gkya wrote: post #14

Earlier quoted context omitted.

When you serve out an entire system for a group of diverse users with lots of installable programs, it's important to ensure that parts will work together. Especially in Unix where namespace clashes in /bin, /lib and /etc may cause serious problem for system administrators and users. Thus, every stable release has to ensure that none of provided software shall do nothing nasty. But with bleeding edge, you lose the co…

> An OS that has to release a version that'll be stable for the coming five years simply cannot provide bleeding edge packages. Wanting software more than every five years is hardly "bleeding edge".

If what you have is fine and works, why want new software? And if you want more frequent updates, you can (a) use a faster-moving branch, which BTW Debian and Ubuntu have; or (b) switch to an OS that provides you with more recent software, e.g. Arch Linux, Manjaro, Gentoo (? not that sure about this last one). Declaring sth. stable takes time, especially if you also incorporate new stuff into it. Even after five years of development, Debian and Ubuntu release patches, because of errata in their releases.

But if you want secure, stable OS that wont drop the eggs, and also rolling release, well, nobody can do anything about it.

Re: Maintainers Matter: The case against upstream packaging

#35

Post by Santosh83 »

gkya wrote: post #32
stormbrew wrote: post #20

Earlier quoted context omitted.

I didn't say I want an entirely bleeding edge system. I said a bleeding edge ubuntu, by which I mean keeping up to date on the non-LTS track (I updated my original post to say that, because I can see where the confusion lies here). Out of the 2500 or so packages installed on the computer I'm typing this on, I want about 10 of them to be bleeding edge. Maybe 20.

So isn't having a separate channel for those 20 that change and update often but thus more prone to risk than the other 2480 packages that you probably would like to work and not bother you a good thing for your productivity and security? Now I last used ubuntu 2-3 years ago and IDK a lot about PPAs, but, what are the shortcomings, exactly? Clashing dependencies (i.e. sth. in your ppa wants libbob 2.0, but ubuntu has…

PPAs would work if they would be widely adopted by all the upstream software whose latest versions people desire AND the PPA infrastructure is adopted by all major Linux distributions so that developers don't need to package in N different formats. But as it stands, leaving it up to distribution maintainers means programs tend to lag several versions behind, while for faster updating each distribution has its own incompatible way, which means developers often give up and don't package at all and leave it to the maintainers, or just select one method like PPA or AUR.

As far as I can see, Snaps/Flatpaks aim to change this, but at the expense of introducing much less manual oversight and inefficiencies in terms of storage, at the very least.

Re: Maintainers Matter: The case against upstream packaging

#36

Post by stormbrew »

gkya wrote: post #32
stormbrew wrote: post #20

Earlier quoted context omitted.

I didn't say I want an entirely bleeding edge system. I said a bleeding edge ubuntu, by which I mean keeping up to date on the non-LTS track (I updated my original post to say that, because I can see where the confusion lies here). Out of the 2500 or so packages installed on the computer I'm typing this on, I want about 10 of them to be bleeding edge. Maybe 20.

So isn't having a separate channel for those 20 that change and update often but thus more prone to risk than the other 2480 packages that you probably would like to work and not bother you a good thing for your productivity and security? Now I last used ubuntu 2-3 years ago and IDK a lot about PPAs, but, what are the shortcomings, exactly? Clashing dependencies (i.e. sth. in your ppa wants libbob 2.0, but ubuntu has…

I'm really not sure what you think I'm arguing here. The situation I have with Ubuntu+ppas is satisfactory to me, and it is also anecdotal evidence that "leave it to the maintainers" (asserted by the OP) is not a complete solution to real problems (my assertion).

Re: Maintainers Matter: The case against upstream packaging

#37

Post by kalessin »

keenerd wrote: post #24
kalessin wrote: post #18

While I agree with a lot of this as well, I feel like downstream packaging has a lot of issues. I'm working on a project (licensed under the GPLv3) and I have decided to be my own maintainer, i.e: building and distributing packaged versions of my project all by myself: 1. my project is young and unknown, I have no choice but to package it myself (I really like AUR by the way); 2. it lets me write and maintain step-by…

I presume you mean lightsd. Nifty stuff. What do you think of Suse's OBS? I believe you're squarely in its target audience. And hats off to you for going the extra mile for your project! Your PKGBUILD even looks quite good. Would you like some assistance in writing a -git pkgbuild for people who want to try the absolute newest commit?

Thank you! Yes, I was referring to my work on lightsd.

I didn't know about Suse's OBS until this thread, I guess I need to look into it. I have been building my own CI/CD pipeline on top of Buildbot so far. It's a PITA, but leaves a lot of room for creativity, hopefully it will be rewarding down the road.

I don't know about the -git thing for PKGBUILD, what's the syntax/documentation?

Re: Maintainers Matter: The case against upstream packaging

#38

Post by mwcampbell »

davexunit wrote: post #3

I 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…

I wonder if the Nix approach would be more popular if a schism (between Nix and Guix) hadn't developed so early. When you talk about Nix and Guix, a novice's natural first question is, "Which one do I use?"

Re: Maintainers Matter: The case against upstream packaging

#39

Post by thinkingkong »

ramblenode wrote: post #23
davexunit wrote: post #3

I 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…

Snappy, Docker et al. are the newest beasts in the evolution of packaging solutions. Nix and Guix decided evolution was too slow and to skip ahead an epoch or two.

Nix was started before docker

Re: Maintainers Matter: The case against upstream packaging

#40

Post by eldude »

Not to get unnecessarily political, but there is almost certainly an analogy to be drawn here to American federalism and the state v. federal government interplay on behalf of their citizens.

Taking the analogy further, the App Store trend is analogous to the 17th amendment[1] superseding the states' right to appoint senators. The relevant implication being that tribal power inevitably gravitates toward centralization on behalf of the "user."

[1] https://en.m.wikipedia.org/wiki/Seventeenth_Amendment_to_the...

Post reply on HN