FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 02-05-2010, 10:28 PM
Aaron Griffin
 
Default Fwd: Perl packaging guidelines.

Message below is trimmed, but the summary is:
pacpan (CPAN wrapper for pacman packages) has been updated with gusto.
There is a request to include using pacpan as part of the official
guidelines for packaging perl apps for Arch. I think this is a good
idea, but it leaves me wondering what we should do with the tool
itself - should we be hosting it in the git repos?

What do you guys think?


---------- Forwarded message ----------
From: Xyne <xyne@archlinux.ca>
Date: Fri, Feb 5, 2010 at 6:18 AM
Subject: Perl packaging guidelines.
To: aaron@archlinux.org


Hi Aaron,

You're probably at least vaguely aware of a tool that I wrote a while
ago named pacpan, which can autogenerate PKGBUILDs for CPAN packages.
In the past worked well enough in most cases but there was room for
improvement and I finally found the time to rewrite it recently.

It is now a very useful tool for packaging CPAN distributions. I don't
want to bore you with the details but it now does the following:

*) correctly maps all modules to their distributions
*) maps distributions to unique pacman pkgnames which follow the
guidelines
*) detects depends, makedepends, optdepends, and provides
*) can detect missing provides for installed packages
*) can update the local database provides while waiting for the
packager to update it

The provides are actually really important because many official
packages do not list the packages that they provide and/or deviate from
the standard naming conventions and this causes problems when trying to
install other CPAN packages. Patching the local database works but it's
an ugly hack.

I've posted a thread on the forum to discuss changing the perl
packaging guidelines to officially recommend using pacpan as a starting
point for all CPAN packages. In most cases the PKGBUILD it generates
should work out of the box. In those when it doesn't, it will still
provide a comprehensive provides array and contain the correct name.
This will improve the CPAN packaging situation by enabling full
dependency resolution and by preventing conflicts from people
effectively packaging the same packaging under different names and
omitting the provides of those packages.

...snip...

If I get some sort of official approval for this proposal, I will
update the Perl packaging guidelines page in the wiki and begin to open
tickets on the bug tracker to update/fix current CPAN packages which
are incorrectly named and/or lack complete provides arrays.
 
Old 02-06-2010, 02:29 PM
Allan McRae
 
Default Fwd: Perl packaging guidelines.

On 06/02/10 09:28, Aaron Griffin wrote:

Message below is trimmed, but the summary is:
pacpan (CPAN wrapper for pacman packages) has been updated with gusto.
There is a request to include using pacpan as part of the official
guidelines for packaging perl apps for Arch. I think this is a good
idea, but it leaves me wondering what we should do with the tool
itself - should we be hosting it in the git repos?

What do you guys think?



I'm not sure about the idea.

From what I understand, Perl comes in CPAN "distributions", which
contain some modules. We take a "distribution" and make a package.
This script fills out a provides array with all modules that are part of
the package and makes the dependencies be these modules. That may be
technically more correct, but the sacrifice is a lot of complexity that
I am not sure is really needed.


How often do modules swap from one "distribution" to another?
Robustness to that is the only advantage I see here. I might be missing
something...


Saying that, in total perl modules on my system are what is needed for
SDL_perl (yay frozen bubble!) and that is the limit of the perl
packaging I have to deal with.


Allan
 
Old 02-06-2010, 03:30 PM
Paul Mattal
 
Default Fwd: Perl packaging guidelines.

On 02/06/2010 10:29 AM, Allan McRae wrote:

On 06/02/10 09:28, Aaron Griffin wrote:

Message below is trimmed, but the summary is:
pacpan (CPAN wrapper for pacman packages) has been updated with gusto.
There is a request to include using pacpan as part of the official
guidelines for packaging perl apps for Arch. I think this is a good
idea, but it leaves me wondering what we should do with the tool
itself - should we be hosting it in the git repos?

What do you guys think?



I'm not sure about the idea.

From what I understand, Perl comes in CPAN "distributions", which
contain some modules. We take a "distribution" and make a package. This
script fills out a provides array with all modules that are part of the
package and makes the dependencies be these modules. That may be
technically more correct, but the sacrifice is a lot of complexity that
I am not sure is really needed.

How often do modules swap from one "distribution" to another? Robustness
to that is the only advantage I see here. I might be missing something...

Saying that, in total perl modules on my system are what is needed for
SDL_perl (yay frozen bubble!) and that is the limit of the perl
packaging I have to deal with.


Where the rubber hits the road on these issues is packaging software
that requires perl modules. Most that I've encountered require
particular versions (or greater) of particular perl modules.


It's then the job of the perl-module-dependent packager to try to figure
out what version of perl incorporated that module. Then as perl
incorporates more modules into the main distribution, all the
perl-dependent packages must be changed/updated. There are a lot of
packages with perl module dependencies.


As at least one step, it seems a good idea for perl to fully list the
component module provides for what it includes in the distribution. This
is would seemingly benefit packagers of perl-module-dependent packages
greatly, and it doesn't add complexity over what we currently have (a
partial such set of provides).


As for the rest of the proposal, it's less clear to me the right path.
Perhaps others will have experience to share here.


- P
 
Old 02-06-2010, 11:56 PM
Aaron Griffin
 
Default Fwd: Perl packaging guidelines.

---------- Forwarded message ----------
From: Xyne <xyne@archlinux.ca>
Date: Sat, Feb 6, 2010 at 2:32 PM
Subject: [arch-dev-public] Fwd: Perl packaging guidelines.
To: aaron@archlinux.org

Hi,

Sorry that I'm posting outside of the thread. I just subscribed to the
list so I didn't have the previous messages to reply to.

> I'm not sure about the idea.

> From what I understand, Perl comes in CPAN "distributions", which
> contain some modules. We take a "distribution" and make a package.
> This script fills out a provides array with all modules that are part
> of the package and makes the dependencies be these modules. That may
> be technically more correct, but the sacrifice is a lot of complexity
> that I am not sure is really needed.

> How often do modules swap from one "distribution" to another?
> Robustness to that is the only advantage I see here. I might be
> missing something...

I didn't understand what you meant by "makes the dependencies be these
modules".

You're right that pacpan fills out the provides array with the modules
contained in a distribution and that modules do not jump between
distros very often. I considered that as well, but that is not a rule
and distributions are occasionally split and merged. This would prevent
breakage in such cases.*

The real advantage of this is that the metadata provided by CPAN
distributions in META.yml files often specify specific modules, not
distributions. The upstream packagers and CPAN itself obviously think
that this is the right way to do it, probably for the aforementioned
possibility of splits and mergers.

Including the provides, depends, makedepends and optdepends (with
occasional tweaks) produced by pacpan is hardly difficult for the
packager and that is exactly what these arrays are for. It thus
guarantees that pacman can handle dependencies regardless of what
happens upstream and it follows CPAN's packaging standards, which is
thus in line with Arch's goal of being as vanilla as possible.

Coincidentally, the Arch Haskell group recently decided to make it
official policy to explicit list provides and depends in all Haskell
PKGBUILDs because they've found that this is a better solution for
long-term dependency handling.

Considering how this simply uses existing pacman functionality, I don't
really understand your argument about complexity either. All the
packager has to do "pacpan --get-pkgbuilds <foo>" and check the output,
then, after installation, optionally run "pacpan --check-local" to
double-check. This presents no added complexity to pacman itself. This
is far simple than not specify explicit dependencies and dealing with
breakage when it occurs. The latter approach is lazy and short-sighted
in my opinion, especially in light of how trivial it would be to
prevent.

Aside from the comprehensive arrays, pacpan will also recommend
standard names for modules which do not have them, and this makes
finding packages easier if applied to all packages in the official
repos as well as the AUR and elsewhere. It prevents conflicting and/or
redundant packages which package the same distribution under different
names, it turns up the correct package when searching for modules, etc.



Having a tool which provides a standardize starting point for all CPAN
modules should be a good thing and I think it could do for Perl packages
what cabal2arch has done for Haskell packages.



* Just to show that this actually does happen, this is from my
pacman.log:

The following official packages can be removed since the modules are
now included in the standard perl library:
perl-archive-tar perl-compress-raw-zlib perl-compress-zlib
perl-extutils-cbuilder perl-io-compress-base perl-io-compress-zlib
perl-io-zlib perl-module-pluggable perl-pod-escapes perl-pod-simple
perl-module-build perl-version

These community packages are also included in the standard perl library:
perl-archive-extract perl-cpanplus perl-digest-sha perl-file-fetch
perl-extutils-parsexs perl-ipc-cmd perl-locale-maketext-simple
perl-log-message perl-log-message-simple perl-module-corelist
perl-module-load perl-module-load-conditional perl-module-loaded
perl-module-pluggable perl-object-accessor perl-params-check
perl-term-ui perl-time-piece

As you can see, things do change and having explicit dependencies will
only prevent breakage.


Regards,
Xyne
 
Old 02-07-2010, 02:18 AM
Paul Mattal
 
Default Fwd: Perl packaging guidelines.

* Just to show that this actually does happen, this is from my
pacman.log:

The following official packages can be removed since the modules are
now included in the standard perl library:
perl-archive-tar perl-compress-raw-zlib perl-compress-zlib
perl-extutils-cbuilder perl-io-compress-base perl-io-compress-zlib
perl-io-zlib perl-module-pluggable perl-pod-escapes perl-pod-simple
perl-module-build perl-version

These community packages are also included in the standard perl library:
perl-archive-extract perl-cpanplus perl-digest-sha perl-file-fetch
perl-extutils-parsexs perl-ipc-cmd perl-locale-maketext-simple
perl-log-message perl-log-message-simple perl-module-corelist
perl-module-load perl-module-load-conditional perl-module-loaded
perl-module-pluggable perl-object-accessor perl-params-check
perl-term-ui perl-time-piece

As you can see, things do change and having explicit dependencies will
only prevent breakage.


I'm +1, but don't feel very strongly about this.

I see that it's more complex than what we have now, but I think the
world of perl dependencies is pretty complex, and the existing system
isn't great at handling either. Modeling it in this more complete way
and mirroring the upstream model seems like a good long-term choice in
terms of reducing work for packagers.


- P
 
Old 02-07-2010, 08:47 PM
Firmicus
 
Default Fwd: Perl packaging guidelines.

On 06/02/2010 00:28, Aaron Griffin wrote:

Message below is trimmed, but the summary is:
pacpan (CPAN wrapper for pacman packages) has been updated with gusto.
There is a request to include using pacpan as part of the official
guidelines for packaging perl apps for Arch. I think this is a good
idea, but it leaves me wondering what we should do with the tool
itself - should we be hosting it in the git repos?

What do you guys think?




This is an area where I have a pretty solid experience, as as perl dev,
arch user, and maintainer of several perl packages in extra and
community. I tend to agree with Allan here. We should only package and
take into consideration what on CPAN is called a distribution, i.e. a
tarball containing a bunch or related perl modules. The mapping between
modules and distributions is available in a plain text database on each
CPAN mirror, and can be figured out by the common tools used to install
cpan stuff from the command-line (cpan and cpanp). I think it is quite a
BAD idea to put all module names in the provides array, as this can
easily yield hundreds of elements without obvious advantage I can think
of. Our poor lil Pacman has better things to do than take that overload
into account.


That said, I do acknowledge Xyne's effort! I have written a very similar
tool years ago, which is still available in AUR (perl-cpanplus-pacman),
but for which I have alas not dedicated as much effort and commitment as
Xyne did with pacpan. My own approach has however inspired another
project, called perl-cpanplus-dist-arch (also in AUR), which IMHO is
superior to both my own cpan4pacman and Xyne's pacpan. (That said I
still use cpan4pacman (together with a few helper shell scripts and the
devtools) to maintain my own local repository of 550 CPAN packages, all
of which I keep uptodate with relative ease).


So -1 from me: the added complexity this proposal would bring clearly
outweighs its advantages!


But OTOH I am fine with the idea of hosting pacpan on git, it is a good
tool. I just don't want the policy it adheres to become our official one.


F
 

Thread Tools




All times are GMT. The time now is 08:05 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org