You are not logged in.

#1 2020-02-16 03:12:12

incomplete
Member
Registered: 2020-02-16
Posts: 1

Minimal updates

The problem:

When you want to install some package, using the command `pacman -Syu <package-name>`, it will update the entire system, sometimes this includes some low level packages such as the kernel, the mesa driver, the nvidia dirver, these low level packages often requires a reboot to functional correctly, if you don't reboot after updating such packages, some wired problem would appear.

There are many apps open when I do the update, a reboot would require me to reopen all these apps, and manually restore to the state before the reboot, this decrease the productivity, especially if you often need to try some new package.

Is there any effort in the arch community to solve this issue? Maybe in the form of introducing a new option such as `pacman -Sy --closure-only <package-name>`, where the `--closure-only` means that, it will only update `<package-name>` and the dependency tree of  `<package-name>`, and leave other packages untouched, even if they are behind the latest version in the repo.

Please do not suggest me to use some other distro, I love archlinux, I just don't like the collateral damages (installing a new package cause some irrelevant (to the new package) part of the system to be broken).

Last edited by incomplete (2020-02-16 03:19:13)

Offline

#2 2020-02-16 03:27:55

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

Re: Minimal updates

It's not an issue to "solve", it is inimical to a rolling release: https://wiki.archlinux.org/index.php/Sy … nsupported


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

#3 2020-02-16 03:59:56

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Minimal updates

incomplete wrote:

Is there any effort in the arch community to solve this issue? Maybe in the form of introducing a new option such as `pacman -Sy --closure-only <package-name>`, where the `--closure-only` means that, it will only update `<package-name>` and the dependency tree of  `<package-name>`, and leave other packages untouched, even if they are behind the latest version in the repo.

If your closure finds that readline is a part of the dependency tree of the package you are updating, then it will update readline, and break bash unless you follow the dependency tree backwards to find all dependencies, then forwards to find all reverse-depedencies of each dependency. And readline is a dependency of pcre, which means it is a dependency of glib2, and therefore gtk3, which is lots and lots of stuff.

If your closure finds that glibc is a part of the dependency tree of the package you are updating, then it will update glibc.

This is exceedingly bad for your use case, because glibc's libc.so is in fact a depedendency of practically everything (at some point, all dynlinked ELF executables and even scripts which depend on a dynlinked interpreter link to libc and depend on it -- and everything is built dynlinked, per default). So following the previous logic, any package that you want to install via a closure, will update glibc, which will in turn force you to do a full system update. (This is actually wrong, because glibc is backwards compatible. New versions of glibc always support the ABI necessary to run programs built using a previous version of glibc, so it is usually very safe to upgrade glibc in a partial update, at least as far as libc.so ABI is concerned.)

Bottom line: these changes snowball back and forth, and anything you try to invent will end up either broken in concept, or else pulling in way way more than you wanted, to the point where you might as well do a full system update.

...

There is, in fact, a feature that supports your desires already. It's what Debian, Fedora, and various other distros use, and it's called versioned dependencies. The problem is that this is extremely awkward to handle and properly support for a rolling release distribution, most especially if you care about compatibility for more than just shared library sonames, i.e. ABI versioning (and there are lots of ways to break compatibility for packages on the API level rather than the ABI level, e.g. python/perl/ruby module versioning).

Gentoo tries to solve this a different way, by providing programs that search your system for broken binaries, and rebuilding all of the affected packages. An ELF binary ABI solution only -- the issue of API versioning is solved by extensive work in declaring ebuild version constraints.

pacman supports ABI versioning via dependency specifiers for libfoo.so, which automatically get constructed as an ABI versioning dependency. pacman also supports API versioning, if the package maintainer manually keeps track of this in their PKGBUILD.

*Arch Linux* supports neither as valid use cases, as jasonwryan pointed out. It's a matter of principle.

Some packages may contain ABI versioning, if the maintainer feels like it, but as a general rule of thumb it's considered annoying, since it also prevents you from upgrading a package and then rebuilding the package which depends on it (this problem is magnified by the AUR, where you cannot sync the version someone else already built for your ABI). As for API versioning, no one bothers to try to keep track of this at all.

We don't support it in the first place, so why should we go to extensive effort for something that is useless unless we intend to actually support it? The ABI versioning, as incomplete and honestly useless as it is, can at least be handled automatically with zero effort. A zero-effort solution is something that someone might bother to implement.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#4 2020-02-16 11:23:01

xerxes_
Member
Registered: 2018-04-29
Posts: 665

Re: Minimal updates

Maybe a partial workaround would be to autostart your apps after reboot (after full system update) and for the state of this apps you have to take care of yourself.

Last edited by xerxes_ (2020-02-16 11:25:04)

Offline

#5 2020-02-16 11:49:47

Slithery
Administrator
From: Norfolk, UK
Registered: 2013-12-01
Posts: 5,776

Re: Minimal updates

Why not just try using pacman -S <pkgname> first?

Depending on how up to date your system is and when the package was last updated this may work fine.


No, it didn't "fix" anything. It just shifted the brokeness one space to the right. - jasonwryan
Closing -- for deletion; Banning -- for muppetry. - jasonwryan

aur - dotfiles

Offline

#6 2020-02-19 14:21:16

Zod
Member
From: Hoosiertucky
Registered: 2019-03-10
Posts: 629

Re: Minimal updates

Slithery wrote:

Why not just try using pacman -S <pkgname> first?

Depending on how up to date your system is and when the package was last updated this may work fine.


This!

I treat Installing a package and updating the system as 2 different processes. If I need a package I install the package and continue to work.

Updating the system is something I do when I can afford to reboot the system (whether it might be required or not).

Honestly, it didn't even occur to me to do ..

sudo pacman -Syu <package name>

Offline

Board footer

Powered by FluxBB