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

[Hilmar L. <hl...@gn...>]

Ah - I think I misunderstood Jason - he probably meant when installing 
the RPM you ignore certain dependencies? So why don't you allow people 
to ignore dependencies?

I'll stick to my guns here that I don't think this is a good approach, 
and not just due to DBD::Oracle. Why do you want somebody to install 
DBD::Pg if she doesn't have or intend to use PostgreSQL? What are you 
going to tell a sysadmin who wants a clean system? Why install all 
kinds of esoteric packages into somebody's perl installation without 
even asking, and even without some of them working?? Why does CPAN ask 
before it gets and installs a dependency?

My opinion anyways, and I'll shut up with this.

	-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
-------------------------------------------------------------