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

Allen Day allenday at ucla.edu
Fri Jan 28 20:09:11 EST 2005


it's no different than lying about what the package provides.  you're
still going to have components in the package that will not function,
because all package dependencies have not been installed.

patching out the dependent code is really the most honest and least
problematic solution here.

-allen


On Fri, 28 Jan 2005, Hilmar Lapp wrote:

> BTW,
> 
> %define _use_internal_dependency_generator 0
> 
> is not an option?
> 
> 	-hilmar
> 
> On Jan 28, 2005, at 4: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
> >>>
> >>
> >>
> 


More information about the Bioperl-l mailing list