Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#5071 - packages should have library dependancies and not just file dependancies.

Attached to Project: Pacman
Opened by Hussam Al-Tayeb (hussam) - Wednesday, 19 July 2006, 01:16 GMT
Last edited by Dan McGee (toofishes) - Thursday, 24 July 2008, 03:11 GMT
Task Type Feature Request
Category
Status Closed
Assigned To Jason Chu (jason)
Architecture not specified
Severity Low
Priority Normal
Reported Version 0.7.2 Gimmick
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Packages should not only have packages dependencies but library dependencies as well. The benefit will come when there is another openssl and db transition.
when a package is built, ldd should be automatically ran and the output is parsed and any important information is stored inside the package. Pacman should be able to handle this. So for example when openssl is updated, pacman will spit out an error, unless all packages dependent on the old openssl are updated at the same time. In that case pacman would build dependency data and see what packages can actually be upgraded.

Of course, there will still be existing packages that are already built without this functionality and pacman should understand that some packages are built the old way and allow you to install them based on package dependencies only.

I think rpm has something similar to this though I'm not sure. In any case, this would really help in future openssl or similar transitions.
This task depends upon

Closed by  Dan McGee (toofishes)
Thursday, 24 July 2008, 03:11 GMT
Reason for closing:  Won't fix
Additional comments about closing:  Responsibility of packager to get versioned deps correct.
Comment by Aaron Griffin (phrakture) - Friday, 08 December 2006, 23:03 GMT
This is already solvable with the current tools. namcap already groks ldd output for compiled binaries. Perhaps we simply need to enforce namcap ldd rules with relation to specific versioned libraries - that is, if ldd spits out "libfoo.so.0.1.2.3" instead of just "libfoo.so", then we need to depend on that version... not really sure.

I'm going to set this as a namcap issue and feed it to Jason. This can already be handled with the >= / <= dependency versioning, we just need more information at build time.
Comment by Jason Chu (jason) - Saturday, 09 December 2006, 00:03 GMT
The problem is that package version numbers don't always relate to library version numbers.

openssl 0.9.8d has a file libssl.so.0.9.8, but what will openssl 0.9.8e have? What about openssl 0.9.9a? How do you abstract that generally? There are far worse examples too.

Namcap could have a message saying that this library depends on a more specific or less specific version (libssl.so.0.9.8 versus libssl.so.0) but that's about it. Again, it's just convention and definitely won't work in all cases.
Comment by Aaron Griffin (phrakture) - Saturday, 09 December 2006, 01:02 GMT
well, what about using the pacman -Qo when a .so.foo.bar library dep is found, to find the owning package?
I'd be even harder in the case of:
libfoo.so.0 as opposed to libfoo.so.0.9.8

But we should at least _try_ to do something with that, even if it isn't perfect.
Comment by Jason Chu (jason) - Saturday, 09 December 2006, 21:25 GMT
Ummm... That's what the depends rule does...

My point is that the so.1.2.3 doesn't map directly (or sometimes even logically) to the version number.

Loading...