[arch-general] Package management
Hello, Before starting, I'd like to remind that we're all humans, so we can discuss these ideas politely and making use of nothing more than reason. I am NOT a pedantic person looking to impose my will; please, excuse me if you feel I'm doing it. I hope this turns into an interesting conversation, and not into an unjustified battle, as it too often does. Recently, I realized I was not using Arch in the way it was "intended"; I was building most of the packages of my system, much "a la Gentoo", with modified PKGBUILDs and a local repository. While it worked with no major inconveniences, I started looking for truly source-based distros, and found Gentoo. However, I disliked some parts about it. This is my attempt at taking what I consider to be "good" ideas to Arch. **Binary packages are right** It is possible to either build packages by yourself, and then store them for later use, or directly take them in prebuilt form. This is specially useful when time matters or when the machine is unable to build things (in my case, I broke a laptop, and it seems it was because of overheating). **Versioning** If I have understood it right, Gentoo makes it possible to have several versions of the same package through "slots". Consider the following scenario in Arch: bar1 -> libfoo-1.0 bar2 -> libfoo-1.0 `libfoo´ is updated to 2.0. `bar2´ catchs up, but `bar1´ does not. Thus, updating `libfoo´ to the latest version would break `bar1´, but is necessary for `bar2´. The solution I've seen is adding the major version number in the package name (e.g. "gtk2", "freetype2"), which would turn the older version of `libfoo´ into `libfoo1´. I think, however, that we could implement Gentoo's "slots", and add the concept of "alternatives". That way, there would be PKGBUILDs for both versions of the library, each with the same name but different version. Each library would be installed as, say, "/usr/lib/libfoo-${pkgver}.so", and an additional script for handling of the named "alternatives" could then create a symlink at /usr/lib/libfoo.so pointing to the right version _if needed_. The script would exist in a per-package basis, so there would only be one for both versions of `libfoo´. For example: $ alternatives-manager libfoo --choose 2.0 ln -s /usr/lib/libfoo-2.0.so /usr/lib/libfoo.so (The name and syntax is just an example.) This is easier to understand with libraries. With programs, however, it's more difficult; someone could want to install different versions of the same program, or, more likely, an outdated version (a typical case would be GNOME 2). We could add "-${pkgver}" to the name of the binaries in such cases, and then use alternatives to create convenient symlinks. It would be horrible to have "cp-8.9.2" and the like. Packages that could benefit from this are freetype, python, and I guess every library out there. It would be, however, hard to implement. **Package selection** When pacman finds several versions of the same package in various repositories, it fetches the one in the prevalent repo. This implies that, if I've configured my local repository before the official repos, I will never notice that a package has been updated. I'll have to do `pacman -Ss pkg-that-ive-compiled´ to check if there's a newer version, or track each project by myself. I think that, if pacman finds itself in the described situation, it should prompt to ask which package to install, unless --noconfirm is passed, in which case it should stick with the default. [If I do `pacman -S repo/pkg´, however, pacman should have no problem in choosing the package, and it shouldn't ask.] These were all the ideas. If you haven't understood something, please ask. Thanks, Kalrish
On 01/05/2014 08:07 AM, Kalrish Bäakjen wrote:
These were all the ideas. If you haven't understood something, please ask. Thanks, Kalrish
All are good ideas, but I think they work against simplicity that Arch tries to maintain. In several cases there are multiple library versions available out of necessity. libpng, libpng12, etc... I understand what you are proposing, but I have a feeling it would be manpower prohibitive to do on any larger scale than what is presently done. The question I have is "What is the criteria that would determine which packages need/get multiple versions?" -- David C. Rankin, J.D.,P.E.
I think that it would be completely up to the Arch developers and to each user. If there's only one application that depends on an outdated version of a library, that application should be patched to work with the newer version. If it's a very big program (say, X), however, or if there are lots of applications depending upon the old version (the Python2 case), then it would be justified to maintain both. Note, however, that the model I propose wouldn't introduce many changes. The python2 package, for instance, would be called simply "python" but have version "2.x.y"; but no more job would be required, since python2 and python packages can already coexist. I have to think more about "alternatives". Instead of the script I proposed earlier, it could be a pacman built-in feature, that simply created symbolic links. As every package would have binaries and libraries versioned, symlinking would be needed to avoid having to use "cp-8.9.4" and the like. If pacman finds itself installing a package for the first time, it should create symlinks automatically; if there's already a package with the same name installed (and with symlinks created), it should just warn that "${pkgname} defaults to ${version-already-set-as-default}". Functionality for alternatives management could be implemented with the "-A" switch: $ pacman -A python=2.7.3 ln -sf /usr/bin/python2.7.3 /usr/bin/python (A possible problem would be UEFI setups in which kernel images reside on the ESP; FAT does not support symbolic links. Maybe copies could be used as a fallback.) There are also directories in /usr/lib that should be renamed. For example, /usr/lib/{systemd,kmscon,chromium}. Configuration in /etc could be other problem (I wouldn't like seeing /etc/X11-15.1.0). Please note that outdated versions would NOT be held in official repositories. However, as official PKGBUILDs are in an SVN tree, an user could checkout the desired version and build it for himself/herself (if I have understood it correctly). Regards, Kalrish On Jan 6, 2014 1:54 AM, "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
On 01/05/2014 08:07 AM, Kalrish Bäakjen wrote:
These were all the ideas. If you haven't understood something, please ask. Thanks, Kalrish
All are good ideas, but I think they work against simplicity that Arch tries to maintain. In several cases there are multiple library versions available out of necessity. libpng, libpng12, etc... I understand what you are proposing, but I have a feeling it would be manpower prohibitive to do on any larger scale than what is presently done.
The question I have is "What is the criteria that would determine which packages need/get multiple versions?"
-- David C. Rankin, J.D.,P.E.
On 6 January 2014 09:26, Kalrish Bäakjen <kalrish.antrax@gmail.com> wrote:
Note, however, that the model I propose wouldn't introduce many changes.
You say that, but you also say this:
There are also directories in /usr/lib that should be renamed.
To me, that by itself implies 'many changes'. Forgive me if I misunderstood the context, though.
Please note that outdated versions would NOT be held in official repositories. However, as official PKGBUILDs are in an SVN tree, an user could checkout the desired version and build it for himself/herself (if I have understood it correctly).
There is more to it than that -- we'd have to keep full sources [1] for every version we support. While that's not anything new for binary distributions, it does affect our resources. However, I do support innovations to prevent breakages. Whatever it is, I don't think Judd envisioned slotted installs when he conceived Arch Linux. In fact, Arch was made to move away from such complexities, but that's only my interpretation of its history and purpose. Caveat: I used Gentoo before Arch, not for long but long enough, in 2006/7. [1] ftp://ftp.archlinux.org/sources -- GPG/PGP ID: C0711BF1
I'm sorry. My idea now seems much worse (and it wouldn't be worth implementing it). Regards, and thanks for your time, Kalrish On Jan 6, 2014 8:11 AM, "Rashif Ray Rahman" <schiv@archlinux.org> wrote:
On 6 January 2014 09:26, Kalrish Bäakjen <kalrish.antrax@gmail.com> wrote:
Note, however, that the model I propose wouldn't introduce many changes.
You say that, but you also say this:
There are also directories in /usr/lib that should be renamed.
To me, that by itself implies 'many changes'. Forgive me if I misunderstood the context, though.
Please note that outdated versions would NOT be held in official repositories. However, as official PKGBUILDs are in an SVN tree, an user could checkout the desired version and build it for himself/herself (if I have understood it correctly).
There is more to it than that -- we'd have to keep full sources [1] for every version we support. While that's not anything new for binary distributions, it does affect our resources. However, I do support innovations to prevent breakages.
Whatever it is, I don't think Judd envisioned slotted installs when he conceived Arch Linux. In fact, Arch was made to move away from such complexities, but that's only my interpretation of its history and purpose.
Caveat: I used Gentoo before Arch, not for long but long enough, in 2006/7.
[1] ftp://ftp.archlinux.org/sources
-- GPG/PGP ID: C0711BF1
participants (3)
-
David C. Rankin
-
Kalrish Bäakjen
-
Rashif Ray Rahman