Arch Linux 'stable' repositories for servers?

jryan · 2016-04-20 19:29:31

2ManyDogs wrote:

Really? One paragraph is too long for you to read? That's not really what it says.

If I understand correctly, if you wanted to do a partial upgrade of a package, you'd have to recompile all packages that depend on package to be safe. Of course this only works if there are no ABI changes.

ayekat · 2016-04-20 21:11:31

jryan wrote:

2ManyDogs wrote:
Really? One paragraph is too long for you to read? That's not really what it says.
If I understand correctly, if you wanted to do a partial upgrade of a package, you'd have to recompile all packages that depend on package to be safe. Of course this only works if there are no ABI changes.

No, the issue is simply that the software is not guaranteed to work anymore. The devs (and the [testing] community) do their work to make sure that the "frontline" of updated packages work well together, but they can't guarantee anything for packages that haven't been released/used/tested together. Maybe it still works (then that's fine). But maybe it might also set your machine on fire (then that's unfortunate).

Recompiling is necessary if there is a soname bump for a library. But it's not always enough. Or not always necessary. There are other kinds of incompatibility that may arise. Think of configuration format changes. Or behavioural changes (conflicts because application A suddenly starts doing stuff that application B used to be responsible for - or application A assumes application B to behave in a certain way that is no longer the case - ...)

All these aspects have to be tested in order to consider software to "work well together". And that's quite some work. There is a reason why Debian has an organisational structure that is not far from a country's government: there's just a s**tload of stuff to take care of if you want to ensure compatibility in all directions (forward & backwards). With rolling release, this would become even worse, because while Debian fixes/freezes some concrete package releases and ensures compatibility between those few, a rolling distribution would need to test every.single.minor version bump. In all directions.

The alternative would be to fix some concrete "LTS" package versions, but then we would be back at the principle of a release-based distro, which Arch is simply not.

nbd · 2016-04-20 21:59:29

Cases like this:

https://bbs.archlinux.org/viewtopic.php?id=209572

apparently show that pure rolling release distro probably is not a viable idea.

jryan · 2016-04-20 23:07:17

Apparently, Manjaro linux is trying to make a "stabler" arch: https://wiki.manjaro.org/index.php?titl … positories

Last edited by jryan (2016-04-20 23:13:59)

2ManyDogs · 2016-04-20 23:21:15

jryan wrote:

Apparently, Manjaro linux is trying to make a "stabler" arch: https://wiki.manjaro.org/index.php?titl … positories

http://allanmcrae.com/2013/01/manjaro-l … stability/

I hope that's not too long for you to read...

timg · 2016-04-21 04:47:51

ayekat wrote:

All these aspects have to be tested in order to consider software to "work well together". And that's quite some work. There is a reason why Debian has an organisational structure that is not far from a country's government: there's just a s**tload of stuff to take care of if you want to ensure compatibility in all directions (forward & backwards). With rolling release, this would become even worse, because while Debian fixes/freezes some concrete package releases and ensures compatibility between those few, a rolling distribution would need to test every.single.minor version bump. In all directions.
The alternative would be to fix some concrete "LTS" package versions, but then we would be back at the principle of a release-based distro, which Arch is simply not.

If you look at my original post, this is almost what I am suggesting.

Have repositories with frozen LTS packages.

timg wrote:

There is no doubt in my mind, however, that tools could definitely be built to simplify the process of maintaining version bumps. ie, watching repositories for new tags, helping to cherry pick bug & security patches, ensuring that new packages built by makepkg for stable repos do not do version bumps, and the only updates to the build scripts are patches that have been uploaded by developers.

and I still stand by this. There is no reason why some infrastructure couldn't be coded up to:

1. Pull new CVE releases into a web interface, and attempt to tag CVE announcements against packages
2. Tag maintainers of packages when a new CVE is announced for the maintainer's package.
3. Allow patches to be uploaded to a build script (having something that runs after prepare to allow packages that have been uploaded to be applied).
4. Only allow patches to be applied if they have been uploaded to the web interface.

Yes, it doesn't make it very Arch-like, but that is not the point.

ngoonee · 2016-04-21 07:44:53

timg wrote:

Yes, it doesn't make it very Arch-like, but that is not the point.

At some point you have to ask yourself, if its not Arch-like is it worth the effort trying to build it on Arch? Debian does a really good job (AFAICT) for servers as is, and if you're setting a server up you wouldn't be installing/uninstalling stuff as often as you would on a general-purpose machine, so pacman can't be THAT big of a difference.

If what you want is the latest version of some software but not others, that seems to be a poorly-defined problem which would probably be best solved using gentoo.

ayekat · 2016-04-21 10:44:06

ngoonee wrote:

If what you want is the latest version of some software but not others, that seems to be a poorly-defined problem which would probably be best solved using gentoo.

IIRC, on Debian you can mix packages from Stable and Testing as much as you like without running into issues. Not sure if this also applies to Unstable and Experimental, though.

Otherwise I agree. If the goal is to turn Arch into Debian, one should rather consider using Debian directly.

jryan · 2016-04-21 12:38:24

2ManyDogs wrote:

jryan wrote:
Apparently, Manjaro linux is trying to make a "stabler" arch: https://wiki.manjaro.org/index.php?titl … positories
http://allanmcrae.com/2013/01/manjaro-l … stability/
I hope that's not too long for you to read...

Sorry if I misled you with the TLDR before, I really just meant a summary. Thanks for the link I hadn't seen that.

nbd · 2016-04-21 15:36:43

Just store a bunch of critical packages in a separate directory along with dependencies and run them from there with systend-nspawn or chroot. As for security updates, since there will be only several non-upgrading packages, one can easily monitor whether there any security updates for them.

tho068 · 2016-04-21 20:51:10

I just reinstalled my server with Ubuntu server. Postfix and dovecot has to many issues on upgrades.

Arch is good for desktop.

Arch Linux

#26 2016-04-20 19:29:31

Re: Arch Linux 'stable' repositories for servers?

#27 2016-04-20 21:11:31

Re: Arch Linux 'stable' repositories for servers?

#28 2016-04-20 21:59:29

Re: Arch Linux 'stable' repositories for servers?

#29 2016-04-20 23:07:17

Re: Arch Linux 'stable' repositories for servers?

#30 2016-04-20 23:21:15

Re: Arch Linux 'stable' repositories for servers?

#31 2016-04-21 04:47:51

Re: Arch Linux 'stable' repositories for servers?

#32 2016-04-21 07:44:53

Re: Arch Linux 'stable' repositories for servers?

#33 2016-04-21 10:44:06

Re: Arch Linux 'stable' repositories for servers?

#34 2016-04-21 12:38:24

Re: Arch Linux 'stable' repositories for servers?

#35 2016-04-21 15:36:43

Re: Arch Linux 'stable' repositories for servers?

#36 2016-04-21 20:51:10

Re: Arch Linux 'stable' repositories for servers?

Board footer