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

[Lincoln Stein]

Perhaps we should split the modules into bioperl-db and 
bioperl-db-oracle.

And so forth.

Lincoln


On Friday 28 January 2005 07:49 pm, Allen Day wrote:
> 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

-- 
Lincoln D. Stein
Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724

NOTE: Please copy Sandra Michelsen <michelse at cshl.edu> on
all emails regarding scheduling and other time-critical topics.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://portal.open-bio.org/pipermail/bioperl-l/attachments/20050131/79d67bf9/attachment-0001.bin