[arch-general] Package management
On Sun, Jan 5, 2014 at 3:07 PM, Kalrish Bäakjen <kalrish.antrax@gmail.com> wrote:
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
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!
2014/1/5 Kalrish Bäakjen <kalrish.antrax@gmail.com>:
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
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@gmail.com> wrote:
On Sun, Jan 5, 2014 at 9:06 PM, Temlin Olivér <temlin@gmail.com> wrote:
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.
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@gmail.com> wrote:
participants (4)
-
Darshit Shah
-
Kalrish Bäakjen
-
Leonardo Dagnino
-
Temlin Olivér