Arch Linux

Posting links to thread is just annoying. Please just put the update provides array here.

The forum post contains a request for an official change in packaging guidelines and it would directly affect the packages of perl and perl-libwww, so it would be nice to get their input.

Then again, if clicking a link is too annoying then I have little hope for getting any support for this.


Anyway, I've attached the provides array.

It seems like this is just a fix to the dependency tree that doesn't represent any sort of discussion or complexity.

I will commit this if there's no action or objection by March 2010 bug day.

Kevin?

There is a discussion about how to tackle this on arch-dev-public (well, Aaron forwarded an email there...). I would wait for the outcome of that.

The discussion about using pacpan as a starting point for packages is somewhat independent of this. Perl provides these modules and CPAN packages explicitly require them. They belong in the provides array. What possible objection could there?

The array has been produced by directly checking and loading module files owned by Perl against CPAN modules which are mapped to the Perl package on CPAN. The modules are thus valid and recognized, and the versions are those reported by the installed modules themselves, so they are also perfectly accurate.

@paul
This request is indeed just to fix the current provides array. I only mentioned the other discussion because it would directly affect all Perl packages on Arch.

> What possible objection could there?

This is a question of changing Arch perl packaging policy so it is not as simple as you imply.

They way I see this is that we currently grab a tarball from CPAN and make a single package from that. That tarball may contain one or more modules. You want the provides array to contain the list of all modules in the tarball. That may well be better but are there any edge cases that you have not considered?

e.g. is there _any_ distributions on CPAN which contains more than one module but has a module with the same name as the distribution? That would result in a package "perl-foo-bar" that provides "perl-foo-bar" and "perl-foo-baz" which would be bad.


Also note that this takes the provides array for perl from 112 "packages" to 445 "modules".

But isn't the existing array just deficient in not listing the other dependencies right now? Or are those dependencies somehow part of a logical group that's being handled differently?

It seems to me like the existing package is listing some of its provides and not others, without any apparent reasoning as to which are included and which are not.

It currently provides every "CPAN distribution" provided by the perl package (if not, that is a bug). CPAN distributions are the tarball you download form CPAN and may contain multiple modules. Arch has always worked with "1 CPAN distribtuion == 1 package" and not "1 module == 1 package".

This proposes listing all the modules provided by the perl package. While that is most likely better, doing so is a change in Arch packaging policy for perl packages and has wider ramifications that just the provides array in perl. That is why I am advocating slightly more care be taken when deciding to implement this.

Ah, okay. Thanks for the clarification.

I've replied on arch-dev-public. Maybe we should keep the discussion there to prevent repetition.

I'll quickly reply to this though:

> e.g. is there _any_ distributions on CPAN which contains more than one module but has a module with the same name as the distribution? That would result in a package "perl-foo-bar" that provides "perl-foo-bar" and "perl-foo-baz" which would be bad.

pacpan removes a name from the provides array if it is the same as the pkgname. I also map all modules to a unique distribution (both modules and distributions are represented by keys in hashes). Run pacpan yourself and then inspect the /tmp/bauerbill/pacpan/CPAN_database. Each line follows the format:

<distribution name> <version> <source path> [<module> <version>]

If you find any edge cases that could be problematic for some reason, let me know and I'll address it.

I didn't realize that I don't have write access to that list. I've asked Aaron to forward my message.

Did we ever get any conclusion here? If so, anyone want to recap it? I remember lots of mail on this but not the outcome.

I think the consensus was to not implement.

decision?