[arch-dev-public] hidden dependencies
I want to ask something about our own packaging rules. Right now we don't add any dependencies that are already covered by another. Namcap usually tells you that right. But this makes it hard to do all the .so rebuilds or if you simply want to check over all packages where a pkg foo is a dependency. This is what I use for checking the deps: [andyrtr@workstation64 cvs]$ grep -l libpcap `find . -name PKGBUILD` ./arch/build/base/ppp/PKGBUILD ./arch/build/base/libpcap/PKGBUILD ./arch/build/network/nmap/PKGBUILD ./arch/build/network/ngrep/PKGBUILD ./arch/build/network/tcpdump/PKGBUILD ./arch/build/network/wireshark/PKGBUILD ./core/base/ppp/PKGBUILD ./core/base/libpcap/PKGBUILD ./core/support/ppp/PKGBUILD ./extra/lib/libnetdude/PKGBUILD ./extra/lib/libnids/PKGBUILD ./extra/lib/libpcapnav/PKGBUILD ./extra/emulators/user-mode-linux/PKGBUILD ./extra/network/lft/PKGBUILD ./extra/network/nmap/PKGBUILD ./extra/network/ntop/PKGBUILD ./extra/network/ngrep/PKGBUILD ./extra/network/ulogd/PKGBUILD ./extra/network/etherape/PKGBUILD ./extra/network/tcpdump/PKGBUILD ./extra/network/ssldump/PKGBUILD ./extra/network/ettercap/PKGBUILD ./extra/network/kismet/PKGBUILD ./extra/network/wireshark/PKGBUILD ./extra/network/xprobe/PKGBUILD ./extra/network/tcptraceroute/PKGBUILD ./extra/system/snort/PKGBUILD ./extra/daemons/knockd/PKGBUILD Do you know any way to write some code for namcap or checkpkg to show those hidden "already covered by another dep" dependencies? To run lddd.sh is only a poor solution as it only detects packages that are installed on your system. If not I'd vote to change the old packaging rule and switch to fully shown deps. Andy
Am Sonntag, 7. Oktober 2007 13:58:34 schrieb Andreas Radke:
If not I'd vote to change the old packaging rule and switch to fully shown deps.
Good idea. This might be the only way to make rebuild due to so bumps easier. -- archlinux.de
On 10/7/07, Andreas Radke <a.radke@arcor.de> wrote:
I want to ask something about our own packaging rules. Right now we don't add any dependencies that are already covered by another. Namcap usually tells you that right.
But this makes it hard to do all the .so rebuilds or if you simply want to check over all packages where a pkg foo is a dependency.
This is what I use for checking the deps:
[andyrtr@workstation64 cvs]$ grep -l libpcap `find . -name PKGBUILD` ./arch/build/base/ppp/PKGBUILD ./arch/build/base/libpcap/PKGBUILD ./arch/build/network/nmap/PKGBUILD ./arch/build/network/ngrep/PKGBUILD ./arch/build/network/tcpdump/PKGBUILD ./arch/build/network/wireshark/PKGBUILD ./core/base/ppp/PKGBUILD ./core/base/libpcap/PKGBUILD ./core/support/ppp/PKGBUILD ./extra/lib/libnetdude/PKGBUILD ./extra/lib/libnids/PKGBUILD ./extra/lib/libpcapnav/PKGBUILD ./extra/emulators/user-mode-linux/PKGBUILD ./extra/network/lft/PKGBUILD ./extra/network/nmap/PKGBUILD ./extra/network/ntop/PKGBUILD ./extra/network/ngrep/PKGBUILD ./extra/network/ulogd/PKGBUILD ./extra/network/etherape/PKGBUILD ./extra/network/tcpdump/PKGBUILD ./extra/network/ssldump/PKGBUILD ./extra/network/ettercap/PKGBUILD ./extra/network/kismet/PKGBUILD ./extra/network/wireshark/PKGBUILD ./extra/network/xprobe/PKGBUILD ./extra/network/tcptraceroute/PKGBUILD ./extra/system/snort/PKGBUILD ./extra/daemons/knockd/PKGBUILD
Do you know any way to write some code for namcap or checkpkg to show those hidden "already covered by another dep" dependencies?
Yeah, this is doable, but not always what we want. If I had some lib, say liblol, that was a dep of bash, and my bash script here depends on bash - this packages doesn't need a rebuild due to liblol. I think these situations are rare, and it would be much better to maintain a manual list in these cases. I can whip something up that will list the entire dep tree of a package if you'd like. Can you post it in the bug tracker and assign it to me so that I can keep track of things?
Am Sun, 7 Oct 2007 07:05:43 -0500 schrieb "Aaron Griffin" <aaronmgriffin@gmail.com>:
If I had some lib, say liblol, that was a dep of bash, and my bash script here depends on bash - this packages doesn't need a rebuild due to liblol.
I think these situations are rare, and it would be much better to maintain a manual list in these cases.
Sadly not that rarely. There are almost half of the db and heimdal update affected packages with hidden deps. Formerly we had those "ToDo" list but they got broken due to the repo shuffle. They are also unusable for 2 architectures. Maybe checkpkg should automatically run such a dep check when it detects a .so change. We should also force all devs to use checkpkg/namcap/{repo}pkg to minimize the risk of broken updates. bug filed: http://bugs.archlinux.org/task/8243 Andy
On 10/7/07, Andreas Radke <a.radke@arcor.de> wrote:
Maybe checkpkg should automatically run such a dep check when it detects a .so change. We should also force all devs to use checkpkg/namcap/{repo}pkg to minimize the risk of broken updates.
That sounds good to me. Considering this is what checkpkg is for in the first place, making it more functional is always a good thing.
Sunday 07 October 2007, Andreas Radke wrote: | Maybe checkpkg should automatically run such a dep check when it | detects a .so change. We should also force all devs to use | checkpkg/namcap/{repo}pkg to minimize the risk of broken updates. the day you force devs to use checkpkg for every pkg, i will orphan all my pkgs that contain a .so file in them or are bigger than 1 MB. i support the idea to use checkpkg more often, but it is fundamential to me to have it optional! reasons are the resources checkpkg needs (space, time, connection traffick) that are limited for some of us (i.e. me). i use my proper way to check for soname changes by buffering the FILELIST of the old pkg in the CVS directory tree outside the CVS itself and running a diff on the new and old one. this is of course not very handy if you want to rebuild other peoples pkgs... and storing the FILELISTs of every pkg in the CVS tree is resource-eating, i know. about the hidden dependencies: most of my pkgs contain (in namcap's eyes) redundand dependencies specified with version number exactly because of this. i would also support the decision to include all the direct dependencies in the depends=() array. greetings from the weekend, Damir -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
On 10/7/07, Damir Perisa <damir.perisa@solnet.ch> wrote:
Sunday 07 October 2007, Andreas Radke wrote: | Maybe checkpkg should automatically run such a dep check when it | detects a .so change. We should also force all devs to use | checkpkg/namcap/{repo}pkg to minimize the risk of broken updates.
the day you force devs to use checkpkg for every pkg, i will orphan all my pkgs that contain a .so file in them or are bigger than 1 MB. i support the idea to use checkpkg more often, but it is fundamential to me to have it optional! reasons are the resources checkpkg needs (space, time, connection traffick) that are limited for some of us (i.e. me).
i use my proper way to check for soname changes by buffering the FILELIST of the old pkg in the CVS directory tree outside the CVS itself and running a diff on the new and old one. this is of course not very handy if you want to rebuild other peoples pkgs... and storing the FILELISTs of every pkg in the CVS tree is resource-eating, i know.
about the hidden dependencies: most of my pkgs contain (in namcap's eyes) redundand dependencies specified with version number exactly because of this. i would also support the decision to include all the direct dependencies in the depends=() array.
Ok then... I guess if we want to toss around ultimatums and all that that's fine. So here's mine: keep doing it your way, but the second you break something because you weren't using checkpkg, then you need to start using checkpkg.
I can whip something up that will list the entire dep tree of a package if you'd like. Can you post it in the bug tracker and assign it to me so that I can keep track of things?
Namcap's depends rule can give you that information. You have to run it with the -i option though. "namcap -i <package>" will have the output in there along with "information" output from other rules as well. "namcap -i -r depends <package>" will only give you information output from the depends rule. Remember that the depends rule will only work properly if you have all the dependencies installed for a package (ie. right after you build the package). Jason
participants (5)
-
Aaron Griffin
-
Andreas Radke
-
Damir Perisa
-
Jason Chu
-
Pierre Schmitz