Re: Packaging CPAN modules for Fedora, the Oslo QA Hackathon, CPAN::Porters

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2008-03-07 at 17:19 +0200, Gabor Szabo wrote:
> On Fri, Mar 7, 2008 at 11:55 AM, Ralf Corsepius <rc040203@xxxxxxxxxx> wrote:
> >
> >  On Fri, 2008-03-07 at 10:38 +0200, Gabor Szabo wrote:
> >  > On Fri, Mar 7, 2008 at 10:23 AM, Ralf Corsepius <rc040203@xxxxxxxxxx> wrote:
> >  > >
> >  > >  On Fri, 2008-03-07 at 09:37 +0200, Gabor Szabo wrote:
> >  > >  > Hi,
> >  > >  >
> >  > >  > I see on http://perl-qa.hexten.net/wiki/index.php/OsloQAWorkshop2008
> >  > >  > that probably non of you is going to participate. That's a pity.
> >  > >  > Anyway I am trying to setup some documentation/system that might help
> >  > >  > 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 http://www.szabgab.com/distributions/
> >  > >  > 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 dists
> >  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 ---
#!/bin/sh
owners=$(HOME)/src/fedora/local

lftp \
-c get "https://admin.fedoraproject.org/pkgdb/acls/bugzilla?tg_format=plain"; \
-o $owners/owners.list.raw

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 be supporting
> >  > 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 "users".
Yep, ... ;)

> In Perl - where I am a bit more familiar - I think there are only a few thousand
> 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.
Yes, ...

> In addition many corporate users take the distros as "given". They
> 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
"mutually-share-the-benefits-with-others" distro.

... 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 communities and
> 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 "community-driven/maintained" distros
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
> >  versions.
> 
> 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
> model.
Well, ... It definitely doesn't apply to rpm-based distros such as
Fedora.
 
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 mapping solution
> 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?
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 software.
> >  >
> >  > 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 their dists
> >  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
release".
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 considers the
> >  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
> approved license?
No. We once had the rule to include only package which carry an OSI
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 free" discussion.
ACK.

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
controversial.

> It would be more constructive to give reasonable wishes what would you like
> 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
works.

> 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
> help you?
No. As with any arbitrary package, review will have to look into each
and every individual file a tarball contains, because this is what
legally matters.

> >  > >  - Write better code. There is a lot of junk in CPAN.
> >  >
> >  > 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
> >  CPAN.
> >  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
> for itself....
> Wait, that's not what you are thinking, right?
Absolutely not.

> Maybe they can get away with that as currently most of the Perl community
> uses and recommends CPAN.pm and CPANPLUS as ways of module
> installations *because* there are not enough modules in the various
> Linux distros.
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
> provider.
Exactly.

> So where shall I send my wish list of CPAN modules I would like to see
> in Fedora?
Join Fedora and contribute to it if you need some CPAN modules on
Fedora: http://fedoraproject.org/wiki/PackageMaintainers/Join


Ralf


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Fedora-perl-devel-list mailing list
Fedora-perl-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list

[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Legacy Announce]     [Fedora PHP Devel]     [Kernel Devel]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite Information]
  Powered by Linux