Seems like a strong proposal.
I have a concern with this proposal. Although it proposes to extend the packaging system, I don't see any real mention of which other operating systems, or how the people that operate distributions like Debian and so on would feel about being extended TO.
While FreeBSD does have by far the best package coverage at the present time, if this project isn't aiming for concrete results like "Make RedHat package availability as good as FreeBSD" but just for generalisation in general (so to speak) it's hard to put a value on it...
Adam,
I understand your concert, but believe it stems from a misunderstanding of what I hope to achieve with this proposal (likely due to poor wording on my part).
There will be no obligation for any operating system 'vendor' to accept radical changes to their packaging infrastructure to use BSDPAN. The module simply wrests control of the CPAN installation process long enough to write a packing file, munge paths, and so forth such that the module being installed can be registered in the underlying system's database. If it helps, think of BSDPAN as the glue that will allow CPAN to be treated as just another package repository from the end-user's perspective.
-c
This would definitely be useful. Currently dealing with the various packaging systems on all the different systems I end up doing work on is a bit of a pain. CPAN is the 'best' way of installing, but it frequently gets clobbered by package dependencies, causing modules to spontaneously change versions. Having CPAN co-operate better with the native packaging system would hopefully make this better.
I have said and written many times that IMHO there is a huge need to make lots of CPAN packages available in the various Linux and other distributions.
See the stats I have on
distributions
What I am missing from the proposal is, what Adam has also written, the clear understanding on how the goal of actually getting those CPAN distros into Fedora/RedHat, Debian/Ubunto etc. will be achived?
Have you talked to at least the Fedora and Debian Perl package maintainers?
Better yet, have you talked to the Perl maintainers of the commercial Linux distros?
See
how to reach them
Colin, could you add some comments about those issues to the proposal?
I'm underwhelmed by the proposal's attitude toward milestones. If the proposer wants an hourly paycheck, this is not the right venue. If the work is not done, the proposer does not deserve (full) pay.
That said, I think this type of work is very important. I worked on packaging Perl modules for Fink for a year, but burned out by the work involved. I tried to automate the process, but never was able to get a satisfactory solution. That was before META.yml really caught on, though, so the state of the art is different now.
I'd like to see a resubmission of this proposal (or another applicant) in the next grant cycle with serious milestones. If that happened, I would enthusiastically support the work.
Gabor:
I'll put out some feelers in that direction and let you know what I find out. Obviously the ideal would be to come upon a solution such that BSDPAN (or whatever it evolves into) could be used in concert with a vanilla Perl build, in which case it would only be a matter of making sure the package names generated by BSDPAN harmonized with those in the system's package repository.
Chris:
The grant amount I arrived at was calculated based on what I could make serving food in the school cafeteria over the summer months, adjusted for the fact that if I were to spend that time writing Perl instead I would no longer qualify for discounted room and board. So yes, this money would in a sense represent my 'hourly paycheck' -- while this is work that greatly interests me and I would gladly do, I simply cannot perform it unsupported at this time.
I recognize the inscrutable list of milestones as a weakness of this proposal and do apologize for it. Several of those bullets (full dependency tracking, M::B support...) represent issues raised by Anton during our conversation, and I simply didn't have as much time as I would've liked to work them into a detailed schedule.
-c