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

[Lincoln Stein]

I agree with Hilmar's sentiment.  If it is possible, the RPMs should 
only install what is necessary to bring up the core functionality of 
the modules in question.

Lincoln


On Friday 28 January 2005 04:49 pm, 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/e98fc593/attachment-0001.bin