Re: dynamic dependency check

[Dhanvi K <dhanvik gmx net>]

Hi Scot
> >      I would like my spec file to dynamically pick up rpm requirements
> > depending on the OS on which the RPM is being installed. for e.g. If the
> > RPM is being installed on Fedora box, then the spec should pick up one
> > set of dependency rpms, while if its installing on a RedHat Enterprise
> > box,  then it should pick up another set of RPMS.
> >
> >      I would like to know whether and how this is possible in the spec
> > file ? Thanks for your time and advice
> >   
> Yes this is possible, though it requires that the OS variation be declared in 
> some standard format by the OS...it is "often" found in /etc/. Though there 
> is no standard format. One could use a structure to discover various points 
> of interest on the operating system, but discovering with something is 
> fedora, redhat, debian, slackware, and their various versions. And then one 
> needs to consider user modified systems.
Yeah I realize that detecting various *NX flavors would be difficult
job. My current project 
requirements clearly specify 3 linux flavors ( fedora, mandrake ,
Redhat Enterprise ) on which we are going to support our product, 
hence this would a pretty straight forward task.. I presume
> Generally speaking...and I do say generally...the most important things to 
> know are the kernel type and version, and libc type and version. All the 
> other dependencies are really far too many to try and track/monitor with a 
> spec file. The best thing to do is to make your spec file look for the 
> various "differences" in pieces.  Use the %ifarch and %ifos directives. You
I will check out these directives. 
>  
> can also use shell scriptlets for a great deal of your logic system. But 
> again you are looking at a lot of work. One of the best soiurces of 
> inspiration and consequentially also dispair are teh xfree86 spec files that 
> mharris has developed. They cover a lot of system detection ground and may be 
> of some help.
I will certainly check out the spec file specified.. Thanks for the
patient reply. 
> But be ready for the fact that you aren't really going to be able to cover 
> ever single instance without developing and maintaining the one single spec 
> file becoming a full time job as you try to keep up with all the changing 
> systems. Worry instead about covering standards and creating a standards 
> compliant spec file. Allow users to "customize" the spec files for their 
> needs instead. Keeping things simple will make things easier on your users, 
> trying to cover every possibility will make things harder for you, and will 
> also make things harder for your users when they DO find they must customize 
> your spec file to work for their system.  Not everyone is system builder, and 
> not everyone has the patience to dig through a complex logic structure.
>
> Scot
Dhanvi