[Bioperl-l] Packaging bioperl for Fedora

Sat Mar 31 17:08:42 UTC 2007

Allen et al.,

What happened to the "GMOD" package or packages? I've had some conversations
in the past few months with you-all suggesting that a GMOD package, or
packages, would be useful.

Brian O.

On 3/30/07 8:30 PM, "Allen Day" <allenday at gmail.com> wrote:

> Hi Alex,
> 
> You've aptly noted that there are several classes of packages being
> discussed here, and that they should not be treated equally.  From my
> point of view and of specific relevance to the Bioperl community we
> have at least:
> 
> 1) "regular" CPAN dependencies and their occassional C/C++/Fortran
> dependencies.  These should all be in Fedora Extras, as they are of
> general utility.  Biopackages.net currently hosts about 200 packages
> (.spec files, specifically) that are like this.  Maybe 80 of these are
> needed for Bioperl.
> 
> 2) academic packages, such as BLAT, NCBI Toolkit, CLUSTAL, genscan,
> etc.  From what I've seen, these typically have strange/custom
> licenses that may not be valid for some users.  BLAT has a dual
> licensing scheme for academic and non-academic licensees, for
> instance.  These packages are not of general utility.  For these two
> reasons, my stance is that they should not be included in Fedora
> Extras.
> 
> 3) Bioperl packages.  Several subsets here.  The Bioperl-run libraries
> depend directly on type (2) packages, so aren't appropriate to include
> in Fedora Extras.  Bioperl-live is not really that useful without type
> (2) packages.  It is also sensible to all of the keep the Bioperl-*
> packages in the same repository.  For these reasons, my stance is that
> they should not be included in Fedora Extras.
> 
> 4) Bioinformatics / Comp. Bio. data sets.  These don't have licensing
> problems, but they tend to be large.  Usually in the 10E7 - 10E10 byte
> range.  RPM can not even generate correct metadata for some of them
> correctly if the files are too large (overflow problems).  Probably
> not appropriate to put in Fedora Extras because they are too large and
> not generally useful.
> 
> 5) Bioinformatics-specific System databases / daemons.  These
> high-level packages depend on types (2), (3), and (4), and so are not
> appropriate to put into Fedora Extras.  An example is a BLAT daemon,
> which relies on the BLAT server, as well as NIB-formatted genome
> sequence files.
> 
> That said, there are a lot of type (1) packages in the Biopackages.net
> repository.  If you're interested in migrating the spec files from our
> repository to the Fedora project it would save us (the Biopackages.net
> maintainers) a ton of build and maintenance time, so please feel free
> to take them, just let us know.  If we can reach some agreement on
> where the bioinformatics-specific packages should be maintained/built
> we may be able to work together on these as well.
> 
> -Allen
> 
> 
> On 3/30/07, Alex Lancaster <alexl at users.sourceforge.net> wrote:
>>>>>>> "AD" == Allen Day  writes:
>> 
>> AD> Hi Alex, The Biopackages.net project is still active, we are
>> AD> regularly adding packages to it, mostly R packages lately.  Most
>> AD> of the systems we use are running CentOS at this point, which is
>> AD> why you have not seen support for FC6 yet.  There is nothing
>> AD> preventing building FC6 packages aside from lack of time to set up
>> AD> the FC6 build farm nodes.
>> 
>> Hi Allen and other,
>> 
>> Great news to hear that Biopackages.net is still active!  I would like
>> to help out if possible.  I don't believe in "FUD" either... ;)
>> 
>> AD> If you're interested in packaging BioPerl or other
>> AD> bioinformatics-related software, please join the Biopackages
>> AD> project on SourceForge.  We object to the Fedora Extras FUD
>> AD> tactics used to discourage people from using 3rd party
>> AD> repositories, and suspect they may not want to host some of our
>> AD> data packages, such as the >2GB genome packages.  Biopackages
>> AD> project is likely to partially merge with RPMForge.  We are
>> AD> already discussing with them how best to do it.
>> 
>> The packages that I created which are currently available in Fedora
>> Packages are Perl dependencies which, as I said are useful for
>> packages outside the bioinformatics purview.  I do have a (base)
>> bioperl package in review, but it is not yet released.
>> 
>> As for third-party repos, I don't object to them at all, and for some
>> kinds of projects they are indeed appropriate. (e.g. for non-free
>> stuff like Livna or Freshrpms).  However I do have practical concerns
>> about repository mixing, but I think that it does need to be handled
>> carefully but that co-operation between Fedora and third-party repos
>> can make it work.
>> 
>> For example, one practical concern is that as of the
>> soon-to-be-released Fedora 7, Core+Extras will be merged, so there
>> will be no distinction at the repository-level between formerly Extras
>> packages and formerly Core packages (as of now there are only "Fedora
>> Packages"), which means that it will not be possible for third-party
>> repos to limit their dependencies to just those in a former base set
>> (i.e. excluding Extras).
>> 
>> I agree that a few years ago (circa 2003-2004) there was concern about
>> the way some third party repositories were treated somewhat badly by
>> the (then) Fedora Extras (with some people going so far as to say that
>> third-party repos were bad in principle and should always be ignored
>> which I disagree with too).  But it seems to me that culture has
>> shifted since, with some notable packagers such as Matthias Saou (of
>> Freshrpms) and Axel Thimm (of Atrpms) now contributing packages to
>> Fedora itself.  The process of contributing has also become much
>> simpler and reviews are conducted speedily and efficiently, I had
>> packages in the repository in a matter of a few days from initial
>> submission.  Freshrpms itself now enables and depends on the (old)
>> Extras.
>> 
>> The real question for me, then is what packages it makes sense to go
>> in Fedora, and what packages go in third party repositories.  It seems
>> to me that in the case of Perl packages which could be dependencies
>> for other packages not specific to the third-party repo in question,
>> it makes sense for them to go into Fedora itself, so I think I will
>> continue to package them.  This lessens the load on the third-party
>> repo, while making them available for all other third-party repos.
>> (This is approach that Freshrpms seems to be taking, Matthias has
>> contributed most packages back to Fedora now other than the non-free
>> ones).
>> 
>> At the other end of the spectrum are packages like you mention, genome
>> packages, which may be of concern because of their size and/or highly
>> specialised nature, and, as you say, may make sense to go in a
>> third-party repo like Biopackages.net.  Also packages which can't be
>> packaged by Fedora for legal reasons like Clustal could/should go in
>> Biopackages.net.
>> 
>> In the middle are packages like bioperl itself which are potentially
>> useful to perhaps a wider group of people than the genome packages but
>> may not necessarily be dependencies for other packages.  I lean
>> towards making them part of Fedora so that they will be available of
>> out the box on the planned "Everything" DVD ISO, but I welcome a
>> discussion on this.
>> 
>> As I said, I'm glad to hear that Biopackages.net is alive and well and
>> I welcome a discussion on how upstream Fedora can usefully interact
>> with Biopackages.net (I guess perhaps on the Biopackages.net list).
>> 
>> Regards,
>> Alex
>> 
>> PS.  As the upstream author If you could clarify the license on
>> perl-SVG-Graph, on CPAN (or on the mailing list) that would be great.
>> --
>> Alex Lancaster, Ph.D. | Ecology & Evolutionary Biology, University of Arizona
>> 
>> 
>> 
>> _______________________________________________
>> Bioperl-l mailing list
>> Bioperl-l at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>> 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l