Article - Maintainers Matter: The case against upstream packaging

QuartzDragon · 2016-06-15 21:15:21

A well-written article on the matter. I hope Arch never goes down this path.

Last edited by QuartzDragon (2016-06-17 09:37:39)

teateawhy · 2016-06-16 22:14:27

QuartzDragon wrote:

I hope Arch never goes down this path.

http://snapcraft.io/
Look on the left. It's already too late

Also
aur/snapd 2.0.8.1-2 (16, 15,57)
Service and tools for management of snap packages.
aur/snapcraft 2.10.1-1 (1, 0,42)
Build Ubuntu snappy packages.

EDIT:

Snaps work on any distribution or device.

- Does this include ARM?

Last edited by teateawhy (2016-06-16 22:18:35)

TheChickenMan · 2016-06-16 22:49:54

What exactly are the better alternatives to linux packaging that people look at when they say that it is not a good and well working process as it is? There is windows where there is no standard and to install a program it has to have a pre-created .exe that you have to find somewhere on google. There are phones where appstores are a total wasteland full of old and duplicated programs doing basically the same as all the others and both package stuff full of ads and other harmfull bloat. What exactly is supposed to be the better way?

ayekat · 2016-06-17 08:19:25

It's better than statically linked executables because containers! It's the future! ... and never mind the required duplication of effort and space usage - I mean, there is an abundance of that, right?

*sigh*

But I trust in the Debian maintainers who will pretty unlikely replace their highly elaborated packaging system and strict packaging policies by something that is made explicitly to circumvent distribution package managers.

TheChickenMan wrote:

What exactly are the better alternatives to linux packaging that people look at when they say that it is not a good and well working process as it is?

From the point of view of proprietary software producers, it may sound tempting to think of simply the "Linux Operating System" instead of "Linux Distributions". However, in the end it will simply be like another distribution, since - for obvious reasons - snaps can never be as deeply integrated into the operating system as a regular application, and people will always prefer native software over applications running on top of nested abstraction layers (so what we evenutally get is just another https://xkcd.com/927/).

At worst, there will be a co-existence like with containers and VMs. At best, this will go the same way as the other "disruptive" innovations for the Linux ecosystem proposed by Canonical. ¯\_(ツ)_/¯

Last edited by ayekat (2016-06-17 08:20:32)

Alcasa · 2016-06-17 08:58:07

ayekat wrote:

At worst, there will be a co-existence like with containers and VMs. At best, this will go the same way as the other "disruptive" innovations for the Linux ecosystem proposed by Canonical. ¯\_(ツ)_/¯

Nah, Ubuntu is really good at removing itself from the other linux standards. We will probably get to a point where Ubuntu is to Linux, that OSX is to BSD today.

TheChickenMan · 2016-06-17 09:16:11

Alcasa wrote:

ayekat wrote:
At worst, there will be a co-existence like with containers and VMs. At best, this will go the same way as the other "disruptive" innovations for the Linux ecosystem proposed by Canonical. ¯\_(ツ)_/¯
Nah, Ubuntu is really good at removing itself from the other linux standards. We will probably get to a point where Ubuntu is to Linux, that OSX is to BSD today.

Didn't Ubuntu already remove all visible references to "linux" from their webpage and advertising?

tallship · 2016-06-18 01:05:04

Some things....

This kinda got my ire today:
http://www.cio.com/article/3085079/linu … snaps.html

Even some of the supporting comments point out the misleading obfuscation by addressing the matter of distro communities clamoring to get on board the canonical product adoption. I can't wait to see if RMS weighs in on this one.

FWIW, I just had to take the troll bait and respond - now my post there is awaiting moderation, but here's what I wrote about this *snaps* stuff:

This sounds just like another terminology created to describe statically compiled libraries - it leverages containerization? That not Linux distributionism, for lack of a term, and although I'm a big fan of Docker, and often compile applications with their dependencies statically to avoid what we used to refer to as, "RPM Hell", or for certain apps that aren't compatible with dependencies relied upon by other software on a particular version of a distro, it still doesn't (from the sounds of it) alleviate what Linus said about the aged incorporation of elderly dependencies in versioned systems.
Why Arch would need to worry about this with Pacman, I can't say, and even Gentoo - perhaps we're only looking at distributing binaries?
Thank gawd for Slackware's lack of *dependence* on *dependencies* in its most elegant package management system that allows you to build once with SBo scripts and deploy repeatedly across all of your assets!

I was astonished to see Arch Linux and Gentoo listed - what use would a rolling distro have for such a package management system anyway? If in fact it's really package management in the classic sense.

I'm not even sure where one would begin to improve upon the design and deployment goals of Pacman.... and really, as on commenter said, "How much did Canonical actually pay them to publish that article?

I'd like to see a show of hands from anyone here has actually worked with Canonical on this for Arch. Anyone? (kind of a rhetorical question).

jasonwryan · 2016-06-18 01:10:16

Merging with the pre-exisiting thread...

tallship · 2016-06-18 01:57:05

jasonwryan wrote:

Merging with the pre-exisiting thread...

Thanks @jasonwryan

I looked around first, but maybe coz I was so livid I was unable to find the suitable niche thread within which I could vent.

I actually thought to myself for a minute... "Hey I can't be the only one pissed about these bullcrap statements.... can I?"

Anyway, thanks for merging my post into the appropriate thread

- Bradley -

R00KIE · 2016-06-18 10:00:22

tallship wrote:

I was astonished to see Arch Linux and Gentoo listed - what use would a rolling distro have for such a package management system anyway? If in fact it's really package management in the classic sense.
I'm not even sure where one would begin to improve upon the design and deployment goals of Pacman.... and really, as on commenter said, "How much did Canonical actually pay them to publish that article?
I'd like to see a show of hands from anyone here has actually worked with Canonical on this for Arch. Anyone? (kind of a rhetorical question).

When I saw the news I was a bit surprised, snap packages are on Arch? That was news to me, I didn't see anything in that regard here on the forums, any announcement on the front page, anything on the mailing lists I follow and pacman didn't find anything. Then I searched the AUR and there it was, two(?) lone packages.

The news are just hype, I can't comment about other distros, such as gentoo, but I would guess snap has arrived there as much as it has arrived on Arch, someone packaged it and put it up for download as unofficial packages. I suppose that's what you get when journalists don't have a clue of what they are talking about and just rehash misleading press releases.

Trilby · 2016-06-18 11:54:04

I keep looking back at the article to see what some of the above posts are talking about. Arch was mentioned in the initial disclaimer, and as a minor counter-example where a distro created 'software' with rc.local. No where does that article say that arch linux has/uses/is-getting snap packages.

It is, however, responding to an existing idea that snap packages - or something like them - are the future for all of linux. I think most of us here recognize that as nonsense, but to the "outside world" it may not be so obviously non-sensical. I've had colleagues with computer science degrees who work in computational fields suggest as much that distros would soon disappear as everything would be replaced by docker apps, or whatever they are called.

Not only do these people suspect that is the future, they are actively pushing to make that future a reality. When they write software they release it exclusively as a app-like bundle. If we value the way our system works, it is reasonable to push back and say we like the way it works, there's value in the way it works, and we don't want all of linux to fall into snap/docker/app-store land.

EDIT: nevermind the above. It seems the merged threads were talking about completely different articles. One spouting nonsense, and the other responding (in my view) very well to the nonsense. The posts above seem to responding to the former which is burried in the middle of this thread.

teateawhy · 2016-06-18 13:26:37

I can see that upstream packaging with could be very helpful for Steam.
* Steam installations on archlinux install ubuntu libraries to .local/share/Steam/ubuntu12_32 .
* There is a huge wiki page dedicated to listing game specific libraries.
https://wiki.archlinux.org/index.php/St … leshooting

TheChickenMan · 2016-06-18 13:41:12

teateawhy wrote:

I can see that upstream packaging with could be very helpful for Steam.
* Steam installations on archlinux install ubuntu libraries to .local/share/Steam/ubuntu12_32 .
* There is a huge wiki page dedicated to listing game specific libraries.
https://wiki.archlinux.org/index.php/St … leshooting

Is it a good thing that Steam is dependent on tying itself to a pile of four year old Ubuntu libraries?
I would love to see Steam revamped a bit to run more natively and on more current software.

teateawhy · 2016-06-18 14:09:09

TheChickenMan wrote:

teateawhy wrote:
I can see that upstream packaging with could be very helpful for Steam.
* Steam installations on archlinux install ubuntu libraries to .local/share/Steam/ubuntu12_32 .
* There is a huge wiki page dedicated to listing game specific libraries.
https://wiki.archlinux.org/index.php/St … leshooting
Is it a good thing that Steam is dependent on tying itself to a pile of four year old Ubuntu libraries?
I would love to see Steam revamped a bit to run more natively and on more current software.

Were talking about libraries used by games here as well.

Head_on_a_Stick · 2016-06-18 14:15:48

TheChickenMan wrote:

I would love to see Steam revamped a bit to run more natively and on more current software.

https://wiki.archlinux.org/index.php/St … ve_runtime

On topic: is not Snappy just another *buntu "innovation" like upstart?

xdg-app FTW!

EDIT: sed 's/snapper/Snappy'

Last edited by Head_on_a_Stick (2016-06-18 16:22:59)

nbd · 2016-06-18 14:56:47

Head_on_a_Stick wrote:

On topic: is this not snapper just another *buntu "innovation" like upstart?

Snappy seems just as revolutionary (and controversial) as was/is Systemd.

Leonid.I · 2016-06-21 20:24:59

Trilby wrote:

It is, however, responding to an existing idea that snap packages - or something like them - are the future for all of linux. I think most of us here recognize that as nonsense, but to the "outside world" it may not be so obviously non-sensical. I've had colleagues with computer science degrees who work in computational fields suggest as much that distros would soon disappear as everything would be replaced by docker apps, or whatever they are called.
Not only do these people suspect that is the future, they are actively pushing to make that future a reality. When they write software they release it exclusively as a app-like bundle. If we value the way our system works, it is reasonable to push back and say we like the way it works, there's value in the way it works, and we don't want all of linux to fall into snap/docker/app-store land.

I wouldn't personally mind having Matlab docker image. In fact, this is what I have been doing: install it in a VM, then pack /usr/local/MATLAB and unpack it inside a container, because there is no way that I'm going to run its installer scripts as root.

But one thing that I don't understand is how these snaps are going to deal with low-level libs like glibc? I presume things like libpng/libjpeg can be bundled but bundling glibc would blow things up?

Steef435 · 2016-06-21 22:03:56

Like Leonid.I, I believe there are some cases in which containers are awesome:
- proprietary closed-source software
- complicated server package bundles

If I download a game from The Humble Store or whatever, I want it to just run. I don't need to install this Broken Sword 2 game I've recently downloaded, I just want to play it and get rid of it when I'm done. It doesn't need to fit perfectly into my system or anything like that. I can't tweak the source code or compile it on my system, it just needs to work.

For complicated server packages like a full BBS or something like that, I think it's great to have containers. They're easy to ship, easy to deploy and it's great for testing.

Everything else I would like to integrate properly and work fully optimized on my system without unnecessary complicating overhead. It's pretty clear that containers do not fit those criteria.

I'm not a maintainer so I have basically nothing to base this on, but I think that the only thing software maintainers (so not the packagers but the developers/distributors) should worry about is a proper, understandable makefile. I am eighteen years old, have just graduated from high school so I can read and do simple math, I've been around here on the GNU/Linux world for a while, I would safely say I can read and understand most scripts and source code snippets that come my way (writing them is something entirely else of course), but give me a decently sized software project's makefiles and whatever other black magic they use to cook up a compile line for a compiler and I'm sure I will not be able to figure out what it's doing at all. Do people actually understand how these build systems work? How come automake or CMake scripts are endlessly harder than the Odyssey or Aeneid, while I would believe an average user should be able to build a software project with it (which I thought was the whole purpose of these things in the first place)?

/rant

Last edited by Steef435 (2016-06-21 22:05:00)

ssri · 2016-06-22 06:43:50

Heh, some of the LXQt team weighed in on snappy, as applied to them, when it was suggested in their bugtracker: https://github.com/lxde/lxqt/issues/1054

I wonder if other upstream devs feel the same way, where downstream is trying to prod upstream to do the former's packaging work for them.

Last edited by ssri (2016-06-22 06:47:14)

TheChickenMan · 2016-06-22 07:03:59

Leonid.I wrote:

I wouldn't personally mind having Matlab docker image. In fact, this is what I have been doing: install it in a VM, then pack /usr/local/MATLAB and unpack it inside a container, because there is no way that I'm going to run its installer scripts as root.
But one thing that I don't understand is how these snaps are going to deal with low-level libs like glibc? I presume things like libpng/libjpeg can be bundled but bundling glibc would blow things up?

Not to be too off topic but Matlab installs just fine without root. You just tell it an install location that your user can access and then need to make a custom .desktop entry to launch it.

ssri wrote:

Heh, some of the LXQt team weighed in on snappy, as applied to them, when it was suggested in their bugtracker: https://github.com/lxde/lxqt/issues/1054
I wonder if other upstream devs feel the same way, where downstream is trying to prod upstream to do the former's packaging work for them.

This makes me wonder if the "only" upstream developers that will be bothering to do this are ones producing software that the distribution packagers would previously refuse to package.

Arch Linux

#1 2016-06-15 21:15:21

Article - Maintainers Matter: The case against upstream packaging

#2 2016-06-16 22:14:27

Re: Article - Maintainers Matter: The case against upstream packaging

#3 2016-06-16 22:49:54

Re: Article - Maintainers Matter: The case against upstream packaging

#4 2016-06-17 08:19:25

Re: Article - Maintainers Matter: The case against upstream packaging

#5 2016-06-17 08:58:07

Re: Article - Maintainers Matter: The case against upstream packaging

#6 2016-06-17 09:16:11

Re: Article - Maintainers Matter: The case against upstream packaging

#7 2016-06-18 01:05:04

Re: Article - Maintainers Matter: The case against upstream packaging

#8 2016-06-18 01:10:16

Re: Article - Maintainers Matter: The case against upstream packaging

#9 2016-06-18 01:57:05

Re: Article - Maintainers Matter: The case against upstream packaging

#10 2016-06-18 10:00:22

Re: Article - Maintainers Matter: The case against upstream packaging

#11 2016-06-18 11:54:04

Re: Article - Maintainers Matter: The case against upstream packaging

#12 2016-06-18 13:26:37

Re: Article - Maintainers Matter: The case against upstream packaging

#13 2016-06-18 13:41:12

Re: Article - Maintainers Matter: The case against upstream packaging

#14 2016-06-18 14:09:09

Re: Article - Maintainers Matter: The case against upstream packaging

#15 2016-06-18 14:15:48

Re: Article - Maintainers Matter: The case against upstream packaging

#16 2016-06-18 14:56:47

Re: Article - Maintainers Matter: The case against upstream packaging

#17 2016-06-21 20:24:59

Re: Article - Maintainers Matter: The case against upstream packaging

#18 2016-06-21 22:03:56

Re: Article - Maintainers Matter: The case against upstream packaging

#19 2016-06-22 06:43:50

Re: Article - Maintainers Matter: The case against upstream packaging

#20 2016-06-22 07:03:59

Re: Article - Maintainers Matter: The case against upstream packaging

Board footer