[arch-general] Perl dependencies
Below is an excerpt from the integrity check results from arch-dev-public. It seems like most (if not all) of these are provided by perl, though the actual packages are in AUR. What is the appropriate solution (before anyone says the bugtracker, there are already two bugs about this [1] and [2]). I can think of a few solutions: A) Making sure packages in the provides array are also in the repository B) Checking for dependencies (in just the integrity check, if it's not already in pacman) in the provides array of packages C) Shifting the set of packages below to depend on perl instead If the appropriate answer is not C), I'd be interested in adjusting the Integrity Check code. Just let me know the appropriate solution. MAQ. [1] https://bugs.archlinux.org/task/27111 [2] https://bugs.archlinux.org/task/27109 Missing Dependencies ---------------------- community/cpanminus --> 'perl-extutils-install>=1.46' community/cpanminus --> 'perl-extutils-makemaker>=6.31' community/cpanminus --> 'perl-module-build>=0.36' community/perl-data-optlist --> 'perl-scalar-list-utils' community/perl-devel-patchperl --> 'perl-io' community/perl-devel-patchperl --> 'perl-ipc-cmd>=0.40' community/perl-devel-patchperl --> 'perl-mime-base64' community/perl-device-gsm --> 'perl-test-simple' community/perl-local-lib --> 'perl-cpan>=1.82' community/perl-local-lib --> 'perl-extutils-install>=1.43' community/perl-local-lib --> 'perl-extutils-makemaker>=6.42' community/perl-local-lib --> 'perl-module-build>=0.36' community/perl-package-deprecationmanager --> 'perl-carp' community/perl-package-stash --> 'perl-scalar-list-utils' community/perl-params-util --> 'perl-scalar-list-utils' community/perl-sub-install --> 'perl-scalar-list-utils' community/perl-test-fatal --> 'perl-carp' community/perl-test-fatal --> 'perl-exporter>=5.57' community/perl-test-fatal --> 'perl-test-simple' extra/perl-anyevent --> 'perl-async-interrupt>=1.0' extra/perl-anyevent --> 'perl-ev>=4.00' extra/perl-anyevent --> 'perl-guard>=1.02' extra/perl-libwww --> 'perl-encode>=2.12' extra/perl-libwww --> 'perl-libnet' extra/perl-libwww --> 'perl-mime-base64>=2.1' Missing Makedepends --------------------- community/perl-data-optlist --> 'perl-extutils-makemaker>=6.30' community/perl-devel-patchperl --> 'perl-extutils-makemaker>=6.30' community/perl-dist-checkconflicts --> 'perl-extutils-makemaker>=6.31' community/perl-package-deprecationmanager --> 'perl-extutils-makemaker>=6.30' community/perl-package-stash --> 'perl-extutils-makemaker>=6.30' community/perl-package-stash-xs --> 'perl-extutils-makemaker>=6.30' community/perl-params-util --> 'perl-extutils-cbuilder>=0.27' community/perl-params-util --> 'perl-extutils-makemaker>=6.52' community/perl-params-util --> 'perl-pathtools' community/perl-sub-install --> 'perl-extutils-makemaker' community/perl-test-fatal --> 'perl-extutils-makemaker>=6.30' community/perl-try-tiny --> 'perl-extutils-makemaker' community/perlbrew --> 'perl-extutils-makemaker>=6.42' community/perlbrew --> 'perl-file-temp'
On 01/07/2012 12:10 AM, Qadri wrote:
Below is an excerpt from the integrity check results from arch-dev-public. It seems like most (if not all) of these are provided by perl, though the actual packages are in AUR. What is the appropriate solution (before anyone says the bugtracker, there are already two bugs about this [1] and [2]). I can think of a few solutions:
B) Checking for dependencies (in just the integrity check, if it's not already in pacman) in the provides array of packages
After having a look at the integrity check source, it looks like it should deal with provivions already, but that code is obviously broken. If you could come up with a fix that would be very nice. pacman can deal with provision just fine. Try `pacman -S perl-io`. -- Florian Pritz -- {flo,bluewind}@server-speed.net
After having a look at the integrity check source, it looks like it should deal with provivions already, but that code is obviously broken. If you could come up with a fix that would be very nice.
:-/ It does look like it handles it fine. I _was_ going to ask if I could test things out in my local machine without mirroring a whole repo when it occurred to me that maybe the script is not the bug. The issue is that the provides array in the perl PKGBUILD is dynamically generated via a perl script. If I were a lesser person[1], I might comment on the fact that a package is a make-dependency of itself. So new question: Is it okay if the dbscript ran an external perl script, grabbed the output, and parsed that? For just the provides field? For any field? How many packages use this sort of script (answer - something on the order of tens)? Make an exception for perl? Ask to have the provides array static in the PKGBUILD, even if it's dynamically generated at the source? Or figure out how provisions are actually established in the perl provides.pl and force (slash ask Mr. Justin Davis to) the script to create a bash-style environment variable instead of what it currently does (which seems like just printing the list of provisions)>Abandon it and continue having perl non-errors in the integrity check? Thoughts? MAQ. [1] Also, if I hadn't tried to see what would happen if I `pacman -Rc perl`. Who knew that pacman followed from that set (pacman -> curl -> opennssl -> perl -- I sense a game in the making: What is the longest chain of dependencies to perl)?
Short summary: The last integrity check included some missing dependencies that are actually not missing, but provided by perl. The problem is that these provisions are generate at build time and not included in the PKGBUILD so the check won't deal with them correctly. On 09.01.2012 04:43, Qadri wrote:
After having a look at the integrity check source, it looks like it should deal with provivions already, but that code is obviously broken. If you could come up with a fix that would be very nice.
:-/ It does look like it handles it fine. I _was_ going to ask if I could test things out in my local machine without mirroring a whole repo when it occurred to me that maybe the script is not the bug. The issue is that the provides array in the perl PKGBUILD is dynamically generated via a perl script.
My fault, I totally ignored the fact that it parses the PKGBUILDs when I looked at it.
So new question: Is it okay if the dbscript ran an external perl script, grabbed the output, and parsed that? For just the provides field? For any field? How many packages use this sort of script (answer - something on the order of tens)? Make an exception for perl?
parse_pkgbuilds.sh already sources the PKGBUILD so whatever magic you do in there will work as long as it's not inside build()/package(). The problem is that I probably can't create the array for perl at that point.
Thoughts?
Parsing PKGBUILDs will also create false positives when/if we use libdepends/libprovides since the version part will be added by makepkg and will be missing from the PKGBUILD. As a solution, you can change the check to load the package data from the actual repo database, but you still have to get the makedepends from the PKGBUILD because these are not in the db. That should be fine though because makepkg checks for those before running build/package. One potential problem when doing this is that the database may not be in sync with svn. Currently the packages that are in the tree, but not in the db will be checked so you still notice problems in the tree when the check runs. When you use the database as the primary source problems in the tree would go unnoticed for quite a while because the cronjob currently runs only once a week. Maybe it's because most of the output is the same all the time? At least that's why I skim over the mails. This could be solved by caching the last output for each section and only sending different lines. To make sure we don't missing anything you could clean the cache every now and then (monthly?) so we get the full output. So my solution is to use the database, send only different output and send it more often. Does that sounds like a good idea? PS: This discussion should continue on the arch-projects mailing list. -- Florian Pritz
participants (2)
-
Florian Pritz
-
Qadri