pam src rpm replaced?
Mike A. Harris
mharris at redhat.com
Sun Aug 24 17:24:27 UTC 2003
On Sun, 24 Aug 2003, Joel Young wrote:
>> Such macros are almost never useful in Linux OS's
>> themselves, and they add a large amount of complicated looking
>> ugliness to spec files.
>
>%{__lex} is uglier than /usr/bin/flex ?
Yes, it is. But I wouldn't use either. I'd use "flex" as it is
in the path.
>Do you ever ever ever test rpms with alternate roots? Suppose
>the flex you wanted to use for the build wasn't in the default
>location, but instead in your alternate build root? Wouldn't it
>be nice to not have a custom spec?
Locally, my packages are built for testing purposes and
development in a custom RPM configuration downloadable from my
ftp "hacks" dir on people.redhat.com. It basically builds
everything under ~/rpmbuild
In the Red Hat buildsystem, things are built in chrooted
buildroots, also with customized rpm configuration, some of it
via macro files and some via commandline options IIRC.
We test what we plan on shipping. We don't test if things
compile on Solaris or any other OS, nor do we care, or have
reason to care.
>> While this may inconvenience a solaris user trying to compile one
>> of my src.rpms on solaris, um... sorry, but I'm not trying to
>> make RPM packages that build on solaris.
>
>Agreed 100% for redhat developers.
Then we agree.
>> You'll be very hard pressed to find rpm packages in any distribution
>> that compile without modification on non-Linux systems.
>
>You might be surprised. Perhaps 30 percent build with no modification,
>most with trivial modification.
Perhaps via luck at best. Hardly due to people going out of
their way to make them build like that.
>> There's no incentive to do extra work like that when it slows
>> down development, and gives you zero benefit and you have zero
>> way of testing it, and end up with an ugly looking spec file that
>> is mostly unreadable.
>>
>> That is why.
>
>Then why did redhat include all of the default %{__xxxx} macros in the
>first place?
To allow people who wanted those features the ability to use
them, in their OWN rpm packages. ie: 3rd party software
developers/packagers who wanted those features for their own
software.
>Why did they make relocatable packages?
Ditto. 3rd party software developers/packagers who wanted those
features for their own software.
>Why are the things like sysconfdir etc. configurable? Because
>it was and is useful to redhat I would suppose?
Exactly. Those are defined via macros so that when you're using
a buildroot, your packages get installed into the fake buildroot
(really misnamed "installroot") aka. RPM_BUILD_ROOT, instead of
overwriting files on your actual running operating system during
%install.
When you use %configure, it gets passed the values of all of
those variables automatically, so that the autoconfized package
installs to RPM_BUILD_ROOT not /
>And I would also suppose that having the discipline of using
>them makes things easier internally to redhat in the long run?
>Just supposition on my part tho.
I don't see the point you're trying to make here. RPM has tonnes
of features. Some were added by Red Hat because they enhanced
rpm in ways that make creating and maintaining RPM packages
easier, some enhancements were contributed by other Linux
vendors, some enhancements were contributed by users of other
operating systems. RPM, while used in Red Hat Linux, and
initially created by Red Hat, is a tool which is portable to many
operating systems, and used by developers of many operating
systems to package software for those operating systems.
While RPM "the tool" is portable, that doesn't mean that every
developer out there in the wild, nor every developer of a given
operating system should spend half their time trying to make sure
their actual RPM packages compile and run on 10000 different
OS's.
Many of the features added to RPM were for the benefit of others
who wanted those features for other OS's, not for Red Hat to
personally use in Red Hat Linux, or even care about. IMHO.
>> No, by all means, feel free to vent your frustrations. Just
>> realize that there isn't any incentive or real benefits to
>> developers of any Linux distribution (or external packagers) in
>> trying to make their packages build on 10000 operating systems
>> they don't have access to.
>
>I see benefit at least to external packagers. External packagers
>presumably would like their packages to build easily on at least
>multiple rpm based linux distros. The more they use the spec file
>macro system, the easier that is.
By all means, feel free to create src.rpm packages that compile
and install on every operating system to which RPM is available
for. It's all open source. Feel free to spend as much time as
you like doing this work, and feel free to distribute the results
of your labours via ftp/http/apt/yum/etc. to as many people as
you like, running as many operating systems as you like.
As far as I'm concerned personally for any RPM package I maintain
inside or outside Red Hat Linux, my goal is to make a given
package compile and install and work properly on Red Hat Linux.
I don't care if the package compiles or installs on any other
Linux distribution, or if it compiles or installs on any other
operating system. Life is short, and my priorities are getting
more work done that is personally useful to me, to Red Hat, and
to Red Hat users. I really don't care if my packages ever work
on Solaris to be honest, and I doubt you'll find any large
percentage of RPM packagers out there who feel differently.
>> I will however bet that it is easier for a Solaris RPM packager
>> dude to take my src.rpm and free of cost to them, be able to
>> modify it to build on solaris. I'll even bet that my work would
>> have saved them countless hours of time, and that they'll be
>> thankful they had something to start with instead of writing one
>> from scratch. Ditto for other packages. ;o)
>
>Guaranteed :-) Maybe thousands of hours saved across 460 packages :-)
>And you know, redhat and polish linux packages were by far the easiest
>to port because their spec files had the most discipline.
There you go.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
More information about the test
mailing list