[arch-general] Package management

[Temlin Olivér]

On Sun, Jan 5, 2014 at 3:07 PM, Kalrish Bäakjen <kalrish.antrax at gmail.com>
wrote:
>
> 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


Hello!

It's a nice idea to have, but packages need to link to the proper library
version (eg. libfoo.so.1, not libfoo.so), thus making the repeated linking
unnecesary. If that's a problem, then you can file a bug report.
There already are a lot of symlinks in /lib, to ensure compatibility. If a
new library version brakes old packages (many), than the old library is
released as you said, with corrected dependencies for all packages (see
libpng12 in community).

Handling old versions is nearly impossible, as neither packagers nor
upstream can be bothered to provide support for outdated packages. Even if
Gentoo found a way, the biggest problem would be that it goes against the
Arch Way: outdated packages go to the repos and it would complicate the
system even more, using the libpng example, the AUR contains three
additional packages, making the count 5. Putting these in the official
repos would encourage developers to keep using old libraries for their
projects and force the user to (in your alternatives-manager-style version)
to change library symlinks repeatedly.
So the arch solution to your problem is to notify bar1 upstream, and if
they don't make a solution (usually because debian/ubuntu not having the
new library versions yet), then make a custom patch, or if there are only a
few users, and/or a dead upstream, drop the package, which has a (high)
chance to resurrect in the AUR.

Just bringing up an example search for gnome at the forums around 2011-04
and a few months forth. Dozens of people wanted back the old Gnome 2
(including myself), whined (not me), but to no avail. All the answers were
all no. Arch is not going to support (or even ship) packages that are
out-of-date. The current solution is to use the since-developed MATE and
Cinnamon derivatives.

But I'm just a user, and these are my thoughts, not completely matching the
arch developers' ones.

-- 
Temlin Olivér