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

[Hilmar Lapp]

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