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.
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.
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
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
|
DetailsPackages 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.
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.
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.
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.
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.
My point is that the so.1.2.3 doesn't map directly (or sometimes even logically) to the version number.