[arch-general] Package management

[Darshit Shah]

On Sun, Jan 5, 2014 at 9:06 PM, Temlin Olivér <temlin at gmail.com> wrote:

> 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
>
>
>
When it comes to your point about *Package Selection*, you're overlooking a
serious use case. The [testing] repos. With [testing] and
[community-testing] enabled,  there are loads of packages which are
available in multiple "official" repositories. Asking the user to select
which version to install for each of them is a hassle for the end-user and
also a new way in which systems can be broken. Instead, what we implement
is a repository hierarchy. When you are setting your local repository at
the top, you're violating the hierarchy and hence, it is you, the end-user
at fault.