[arch-general] Package management

5 Jan 2014

      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

Kalrish Bäakjen

David C. Rankin

Kalrish Bäakjen

Rashif Ray Rahman

Kalrish Bäakjen

tags

participants (3)