[arch-general] Perl dependencies

Qadri Muhammad.A.Qadri at gmail.com
Sun Jan 8 22:43:45 EST 2012


>
> 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)?


More information about the arch-general mailing list