Maybe a mechanism could be implemented that warned the user…? Or a setting
in a per-repo basis. (I understand your point. Indeed it would be awful.)
Thanks,
Kalrish
On Jan 7, 2014 8:56 PM, "Darshit Shah" <darnirmlist@xxxxxxxxx> wrote:
> On Sun, Jan 5, 2014 at 9:06 PM, Temlin Olivér <temlin@xxxxxxxxx> wrote:
>
> > On Sun, Jan 5, 2014 at 3:07 PM, Kalrish Bäakjen <
> kalrish.antrax@xxxxxxxxx>
> > 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.
>
