[Bioperl-l] Re: RPMs for Bioperl and GMOD

[Allen Day]

okay, i've looked into this.  short answer: you cannot specify to omit
automatically determined dependencies without "lying" in the rpm specfile
and stating that a package provides a perl module that it, in fact, does
not.

for example, i can add a statement to the bioperl-db rpm stating that it
provides perl(DBD::Oracle), but not actually add DBD/Oracle.pm to the
package.  there is a thread extensively discussing this aspect of the rpm
build system here:

http://www.redhat.com/archives/rpm-list/2004-February/msg00083.html

if i'm making a package for private use only, i don't mind doing this, but
if this package is to be for public consumption i don't want to lie about
what is and is not provided.  i take the same stance on all the other perl
modules in the bioperl dependency tree, including esoteric modules such as
Net::Jabber and GD::Graph3d.

the only viable option i see here is to patch Oracle dependencies out of
bioperl-db.  that is what i will do until i have working Oracle and
perl-DBD-Oracle packages in-hand.

-allen


On Fri, 28 Jan 2005, Hilmar Lapp wrote:

> Like this statement or not, but I think installing all kinds of CPAN 
> packages onto somebody's machine irrespective of whether somebody is 
> ever going to use - or need - them, let alone them working in the first 
> place due to compiled code dependencies being absent, is a really *bad* 
> idea
> 
> It basically defies the concept of modular packaging to begin with, and 
> sounds way too intrusive for my taste.
> 
> Unless I misunderstand what Jason is saying then this is not even 
> necessary and is in no way an inherent shortcoming that inevitably 
> comes with RPMs. So unless I'm missing something here I understand that 
> Jason is saying you can have RPMs and still not litter your system with 
> DBD::blah or other modules for which you don't even have the client 
> libraries installed, and still be able to install those at a later time 
> because the respective pieces of code have not been pruned (which I 
> think is actually also a bad idea).
> 
> 	-hilmar
> 
> On Friday, January 28, 2005, at 11:50  AM, Allen Day wrote:
> 
> >> Do you mean your RPM or bioperl-db on Oracle? I'm running the latter
> >> all the time.
> >
> > i mean the RPM.  it is the same as bioperl-db cvs head as of last 
> > night.
> >
> >>> I'd also like someone with Oracle to help me make a DBD::Oracle rpm.
> >>> Having a DBD::Oracle RPM will allow me to leave the Oracle code in
> >>> Bioperl-DB.
> >>
> >> If installing the supposed DBD::Oracle is then a prerequisite for 
> >> being
> >> able to install the rest, then you are taking the wrong path.
> >> DBD::Oracle itself will depend on the Oracle client libraries being
> >> installed which aren't even available on all platforms, aside from the
> >> fact that installing those is beyond your control and involves
> >> downloading about 350MB from OTN.
> >>
> >> Frankly, I can't believe that there is no way to specify dependencies
> >> that are optional. Why would you require all of DBD::mysql, DBD::Pg, 
> >> and
> >> DBD::Oracle if all a persons wants is mysql?? All of these will link 
> >> to
> >> compiled runtime libraries and why should a failure to install DBD::Pg
> >> be of any concern to someone who wants to use mysql?
> >
> > the problem is something internal to the rpm installer -- it determines
> > perl library dependencies at install-time rather than requiring you to
> > explicitly specify perl packages in the rpm metafiles (aka specfile).
> >
> > so, for instance, if i i tried to install perl-Generic-Genome-Browser, 
> > i
> > might get an error like:
> >
> >   requires perl(Bio::Root::Root)
> >
> > which could be removed by one of:
> >
> >   (1) installing the perl-bioperl package
> >   (2) installing bioperl from cvs
> >   (3) installing bioperl from cpan
> >
> > there may be a way to code into the metafile to ignore missing perl
> > dependencies detected in the installation process -- i need to look 
> > into
> > this.
> >
> >> BTW DBD::Oracle is on CPAN. I thought that would make it easy to
> >> construct an RPM? (There's few if any binaries though - for a reason.
> >> Compiling DBD::Oracle may be a charm on some but involve some major
> >> tweaking on other platforms. I've been there multiple times, I know
> >> what I'm talking about.)
> >
> > given what i've said above, if i had a DBD::Oracle perl module 
> > installed,
> > it would prevent rpm from throwing errors about missing dependency
> > "perl(DBD::Oracle)".  however, i can't build DBD::Oracle into an rpm
> > because the make process links to the oracle headers and .so files.  
> > the
> > DBD::Oracle can be made w/o having explicit dependencies on the oracle
> > binary install, so it would install on a machine that didn't have 
> > oracle
> > installed (but wouldn't work).  so as far as a bioperl-db rpm goes, 
> > here
> > are the options i'm looking into:
> >
> >   (1) get a binary perl-DBD-Oracle rpm built by someone with Oracle,
> >       leaving out the binary Oracle file dependency.  distribute
> >       bioperl-db from cvs as-is
> >   (2) patch Oracle classes out of bioperl-db as part of the rpm build
> >       process.  distribute modified bioperl-db.
> >   (3) modify rpm "detection of installed perl modules" functionality
> >       to have rpm explicitly ignore missing DBD::Oracle dependency.
> >
> > (1) and (2) will definitely work.  i don't yet know the feasibility of
> > (3).
> >
> > -allen
> >
>