[arch-general] Package management

[Kalrish Bäakjen]

Well, my example was about a major API change. Another example would be
Python: we have version 2 and version 3, and both are used. If we had
switched to a Python3-only bleeding-edge setup, we would have ended up with
a big breakage. As we needed both, we renamed the old Python to make it
able to coexist with the newer version.

What I proposed is a scheme in which makepkg, after running package() but
before packaging, did something like this:
for P in "${pkgdir}/usr/bin"/* ; do mv "$P" "$P-${pkgver}" ; done
Although it could break things (e.g.: program calling another program; oh,
where is it?), it would allow to have as many versions of the same package
as we wanted. (It would probably be better to adjust the paths via
'configure'.)

This can be useful in some cases. Aside from the Python example, I could
have multiple X servers and seamlessly benchmark each; I could also have
two versions of the same library if both are needed.

Regards,
Kalrish
On Jan 5, 2014 8:26 PM, "Leonardo Dagnino" <leodag.sch at gmail.com> wrote:

> 2014/1/5 Kalrish Bäakjen <kalrish.antrax at gmail.com>:
> > Hello,
> >
> > Thanks for your explanation. I understand that it's not possible to
> > maintain every version of a package (and, as you've pointed out, it goes
> > against The Arch Way). However, it could still be useful for AUR
> packages,
> > or even official ones (I can't check it, but I was told that Arch keeps
> > official PKGBUILDs in an SVN repository. If that's the case, then it
> would
> > be possible to checkout a specific version of a PKGBUILD, for example, to
> > get an old version of X that is compatible with certain drivers).
> >
> > About libraries, my knowledge is very little. Why do exist the
> unversioned
> > symlinks? I'm sure I'm missing something (perhaps the linker dereferences
> > links) but, if bar1 links with -lfoo, then, if libfoo is updated and
> > libfoo.so now points to a newer version, wouldn't bar1 break?
> >
> > I completely agree with Arch's principles. Mainstream has to be pushed to
> > move on and use newer versions of libraries. I also personally loved
> > GNOME2, but I understand it used what we now consider "old" versions of
> > libraries, so it can't be sustained "as-is".
> >
> > Thanks!
>
> A libfoo upgrade wouldn't break bar1 in most cases (unless there was a
> major API change), because the external interface stays the same
> (again, with exceptions). Library updates usually only change the
> internal implementation and/or add new functions, which means code
> made for previous versions will continue working.
> --
> Leonardo Dagnino
>