[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: RPM Inconsistencies

In regard to: Re: RPM Inconsistencies, Jeff Johnson said (at 12:48am on Feb...:

>> 	%ifos solaris
>> 		# do some long bit of shell code here
>> 	%elsif osf
>> 		# some other shell code
>> 	%elsif irix
>> 		# some other shell code
>> 	%elsif aix
>> 		# shell code
>> 	%elsif hpux
>> 		# more junk
>> 	%endif
>> with modern RPM?  I would *really* like to get with the program, rpm-wise,
>> but our legacy RPMs mean that I have a considerable barrier to getting
>> there.
>Exactly the above syntactical constructs are still alive and well.

Well, yes and no.  %ifos exists, but that chunk of code shown above
wouldn't work, because of the version now being jammed on to the OS.

>What appears to be stopping you from upgrading (aside from the weight of
>maintaining a bunch of software for the entire whore house of unix :-)

:-)  Yeah, I have a unique "appreciation" for the things vendors do
to differentiate their products.

>one single routine
>	static void defaultMachine(/*@out@*/ const char ** arch,
>                /*@out@*/ const char ** os)
>in lib/rpmrc.c where the information returned from uname(2) is mapped
>onto various entirely arbitrary strings, now "os & version", but
>could easily be mapped to whatever you found convenient.

I think you suggested I hack that routine once before, and I think
the reason I haven't pursued it is because that will put me in the
situation where the spec files we use to build software won't work for
stock RPM -- they'll require our special hacked version of RPM.  I would
like to one day be able to share our specs with people (as part of
the RPM world-domination effort), so I haven't wanted to wander down
that path yet.

What I don't understand is why the change was made in the first place?
I agree that the osnames that `%ifos' used in RPM < 3.0 were arbitrary and not
always the best choices (so a change to the more common "GNU config.guess
name for the OS" was a good idea), but I've never understood how jamming
the os version onto it benefits anyone.

For others that are packaging software for multiple OSes using RPM >= 3.x,
how are you handling the fact that it's now "os & version" rather than
just OS?  Are you doing something like:

	%ifos osf3.0 osf3.2 osf4.0 osf5.0 osf5.1
	# do some stuff for OSF/Tru64
	%ifos solaris2.4 solaris2.5 solaris2.6 solaris2.7 solaris2.8 solaris2.9
	# do some stuff for IsALosr


?  It just strikes me that `%ifos' is a lot less useful/scalable now than
it was in RPM 2.5.x.  The next time a vendor releases a new version of
their OS, I don't want to have to modify all 300+ spec files just to
include `foo21.0' in the same %ifos clause as the first 20 versions of

So, how are people dealing with this?

How much breakage would there be if some future version of RPM switched
*back* to using just the osname for `%ifos', but introduced something like
%ifosver or %ifosversion that had the version information?

>And, in fact, if you wanted to minimize the amount of work needed to
>maintain 337 spec files, many %defines that you have found useful
>(which are probably fairly redundant, just a guess) might be factored
>out of spec files into a per-platform configuration file, that would
>be included only on a given platform.

You're right, they are generally pretty redundant, and factoring them
into something platform-specific and/or host-specific is definitely
something I would do if I could get by some of the other things holding me

>Anyways, you're pretty much a special case,

;-) I hear that a lot.

Tim Mooney                              mooney@dogbert.cc.ndsu.NoDak.edu
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []