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

[Hilmar Lapp]

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
>
-- 
-------------------------------------------------------------
Hilmar Lapp                            email: lapp at gnf.org
GNF, San Diego, Ca. 92121              phone: +1-858-812-1757
-------------------------------------------------------------