On Fri, 2008-03-07 at 17:19 +0200, Gabor Szabo wrote:
On Fri, Mar 7, 2008 at 11:55 AM, Ralf Corsepius
> On Fri, 2008-03-07 at 10:38 +0200, Gabor Szabo wrote:
> > On Fri, Mar 7, 2008 at 10:23 AM, Ralf Corsepius <rc040203(a)freenet.de>
> > >
> > > On Fri, 2008-03-07 at 09:37 +0200, Gabor Szabo wrote:
> > > > Hi,
> > > >
> > > > I see on
> > > > that probably non of you is going to participate. That's a
> > > > Anyway I am trying to setup some documentation/system that might
> > > > all the distros to include more CPAN packages more easily.
> > > >
> > > > For this I setup a page collecting information about the
availability of CPAN
> > > > packages in the various distros
> > > > As you can see Fedora is way underrepresented there.
> > > How did you collect these numbers?
> > I wish to count CPAN distros (that is tar.gz files from CPAN).
> OK, then the figure I gave should be pretty close. I counted packages
> using a "perl-" prefix in Fedora's package database. As most CPAN
> in Fedora are packaged into separate rpms prefixed with "perl-" this
> should give a pretty good estimate.
Where can I fetch this list from?
I am using this script:
--- snip ---
-c get "https://admin.fedoraproject.org/pkgdb/acls/bugzilla?tg_format=plain" \
cat $owners/owners.list.raw | grep '^Fedora|' > $owners/owners.fedora.list
--- snip ---
And grep'ed the generated owners.fedora.list:
grep perl- owners.fedora.list
> > > I really have no idea how a distro can be claimed to
> > 8000+
> > > perl-dists, nor how useful such a distro would be. My wild guess is
> > they
> > > are counting differently or contain a lot of duplicated CPAN
> > modules.
> > There are some 13.000 on CPAN so 8000+ is still less than 2/3.
> To put it bluntly: Perl-dists in Fedora are more or less community-only
> maintained, i.e. inclusion of perl-dists in Fedora is more or less
> community demand-driven => There is little demand for these remaining
> 12000 packages, probably because hardly anybody needs them.
In my experience the "community" is a very small subset of the
Yep, ... ;)
In Perl - where I am a bit more familiar - I think there are only a
people involved in the "community" while there are ~ 1.000.000 people writing
Perl code (in various levels) and many more using it hidden in some application.
In addition many corporate users take the distros as
don't even think
they can ask the distro people to include something in the distro.
That means in many cases the users won't ask and you'll think they
don't need the modules.
That's the difference between Fedora and "commercial distros".
Fedora is a "taylor-the-distro-to-your-demands-by-contributing" and
... that's essentially the basis of all open source development, which
makes the fundamental difference to "commercial OSes" ;)
IMHO there is very little communication between the distro
the Perl community. Some Debian people have started a dialog on the last
YAPC in Vienna and I wish we can increase that even further.
The QA Workshop in Oslo would be a great opportunity for that but if none of
you can come then the next YAPC::EU in Coppenhagen can be also good for
more personal contact.
<sigh/> That's fundamental problem
like Fedora and Debian: Volunteers don't have travel budgets ;)
> > > > What if you could have a "wishlist"
that you could present to
> > CPAN module
> > > > authors? What would that contain? What would make life easier for
> > those
> > > > who package CPAN modules for Fedora?
> > > In decreasing priority:
> > >
> > > - Improve your versioning scheme - perl's versioning doesn't
> > harmonize
> > > well with rpm's versioning.
> > Can you elaborate - give a few short examples or at least point me
> > where is it described?
> Example: A perl-dist using a version number of 0.04.
> What does this mean? For rpm, 0.04 equals 0.4. For CPAN this means
> something completely different.
> This raises version comparison problems when perl-dists jump in their
> versions, e.g. 0.04 -> 0.40.
> For rpm, both versions are equal = 0.4 ("null point four"), i.e.
> CPAN/Perl versions need special treatment when mapping them to rpm
The Debian people are saying they don't care too much about what are the
version numbers as long as any single module sticks to its versioning
Well, ... It definitely doesn't apply to rpm-based distros such as
Choosing "versioning models" has always been problematic and
controversial in general, as well as has synchronizing two different
versioning models been problematic.
What we can do is come up (if you have not done it yet) with a
that will easily map most of the CPAN version themes to the way Fedora does it.
We can include this in Kwalitee metrics of CPANTS.
Then when you encounter a module that does not use any of those version themes
you can politely point the author to that document.
There have been dozens of such
cases in Fedora-rpms/CPAN-dists in rpms history :(
So what is the definition of a version number in Fedora?
is rpm based. I.e. it internally applies rpm's versioning scheme.
Unfortunately, elaborating how rpm's versioning works would be beyond
the scope of this mail :(
> > > - Think about the licenses you apply. Write Free
> > Do you have examples you encountered where it is not so on CPAN?
> I don't have a concrete example at hand, but there have been plenty of
> such cases.
> Most CPAN dists apparently are maintained by individuals, who actually
> don't care much about licensing.
You are right on the fact that most distros are maintained by individuals but
I don't seem to be able to find prof for the second part.
Do I have to dig out
the cases we've encountered?
> There are CPAN maintainers who switch from GPL to MIT though
> contain loads of user-contributed code. There are CPAN packages which
> don't have any license information inside. There are CPAN packages
> harvesting code from other packages without thinking about licenses at
> all ...
So what do you do about such cases?
We normally trip over those issues during
package reviews, when trying
to examine a package's license. In most cases, we first try to contact
the upstream maintainer (in case of CPAN dists, the CPAN maintainer)
trying to get a clarifying statement to resolve such issues.
We normally end up with one of these cases:
a) Maintainer responds with a clarifying email
=> if answer is satisfactory, include this email into a package.
b) Maintainer responds with "will include appropriate license in next
c) Maintainer responds with "will not change/can not change license"
=> Package can't be included in Fedora.
d) Maintainer doesn't respond.
=> Package can't be included in Fedora.
AFAICT, Debian does more or less the same.
> You might not be aware about it, but there are people who
> original "Artistic" license to be non-free (One of these groups is the
> FSF: http://www.gnu.org/licenses/license-list.html
Do you say that Fedora includes only code which comes with an FSF
No. We once had the rule to include only package which carry an
approved license, but ... rules have been weakened ... I don't want to
reheat this controversy at this point.
Fact is: Opinions on what to consider Open/Free SW diverge.
Please, let's not go into the "whose license is more
Wrt. CPAN dists in Fedora, the points are:
- Is a particular CPAN dist properly licensed?
Most are, some are not.
- Is it legal for RH to distribute it/Does a dist comply with US laws?
Most are, some are not.
- Does it meet Fedora's criteria on OpenSource licensing?
Most do, some don't. Artistic-v1.0-only licensed packages are
It would be more constructive to give reasonable wishes what would
to see in the CPAN distros - license vise - in order to make it easier
for you to build rpms.
OK, my advice to CPAN module authors:
* Clearly and properly copyright your works.
* Always apply a widely used and commonly acknowledged license to your
Would that be enough for you to have that field or you don't care
about that and
you prefer to have the license in the source files? Is there any
format that might
No. As with any arbitrary package, review will have to look into each
and every individual file a tarball contains, because this is what
> > > - Write better code. There is a lot of junk in
> > Wow, do you have a suggestion how to automatically measure this?
> No. I consider this simply to be a matter of fact due to the nature of
> IMHO, the fact Fedora, Debian, Ubuntu etc. are getting away by not
> shipping 12000+ modules speaks for itself: Most of CPAN is more or less
> dead code, for various reasons.
IMHO the fact that most of the world uses MS Windows and not Fedora speaks
Wait, that's not what you are thinking, right?
Maybe they can get away with that as currently most of the Perl
uses and recommends CPAN.pm and CPANPLUS as ways of module
installations *because* there are not enough modules in the various
CPAN and CPANPLUS are contradicting package managers.
Like any other package manager they do not harmonize well with other
package managers (such as rpm or dpkg).
Linux users are strongly advised not to use them.
It works quite well but there are problems.
The biggest is that CPAN.pm fetches the latest versions and not some
stable version which was tested and integrated by the Operating System
So where shall I send my wish list of CPAN modules I would like to
Join Fedora and contribute to it if you need some CPAN modules on