rpm package building as non-root (was: Re: src.rpm standards)

[Mike A. Harris]

On Wed, 28 Jan 2004, Gene C. wrote:

>Ok, this did not get a rise from anyone on fedora.us so lets try here ...
>
>One thing that has always annoyed me about some packages are the "extra" 
>source files they plug into the SOURCE directory.  While most and all "good" 
>rpms have the package version id on all tarballs, patches, and other 
>"official" files.  Then there are the "extra" files.  These are named 
>absolutely anything.  If your are in the process of building two separate 
>packages but they have a name conflict, you will never know except that the 
>result may not perform/operate as expected and your will never know why.
>
>I am not sure what the standard should be but I believe that there should be 
>one.
>
>While I am comfortable with a package xxx version=2.3.4 having a patch file 
>named xxx-1.2.3-fixit.patch because it was developed on version 1.2.3 but 
>still applies to version 2.3.4, that is OK with me.
>
>But, when some package xxx has a file named perhaps "version", that is 
>something that should not be happening.
>
>I assume that the various automated build systems start with a clean set of 
>directories for each build, this may not be true for individuals (it is 
>certainly not true for me).
>
>OK, what do you call think about this?

The default RPM building heirarchy that is as old as the pyramids 
at Giza, is fundamentally broken in many ways.  One of those 
ways, is because all SPECS are put into one dir, all SOURCES are 
put into another, etc...

However that isn't how humans work.  I don't anyway.  I edit a 
"package", and that package includes a spec file, some patches, 
some source files, and other stuff.  I want to see them all in 
one directory, and I don't want to see any other package's files 
in that directory.  One directory per package which is a work in 
progress to turn into a new src.rpm.  That is what makes the most 
sense for me anyway, however some people will be in the "old 
habits die hard" category and I can certainly respect that, just 
as I can also respect other's who might have different 
preferences from both the default, and my own which I just 
described.

The problem with the default, is playing directory changing games 
to go from editing the spec file, to editing a patch (or 
generating one), or adding a new source file, then changing dirs 
again.  Problem 2, is having 30 src.rpm's installed and all 30 
spec files all in one huge dir.  30 isn't huge?  Ok, make it 300 
packages.  Find the one you're looking for.  Then try to find 
it's patches and sources in the SOURCES dir, along with the 
plethora of crap from 300 other packages, all of which are 
intermixed in alphabetical order with each other, and you've no 
easy way to navigate to the right files you want.  For 300 
packages, the directory SOURCES probably has 1000-2000 files in 
it.  Fantastic for navigating both at the commandline as well as 
with a file manager</sarcasm>

Ick ick ick.

The best part, is when you install package1 and it has a file 
named LICENSE, and package2, package3, and package4 also have 
files named LICENSE, all of these packages listing them on a 
"Source" line in the spec file. Also assuming all 4 packages, 
that those 4 LICENSE files are completely different contents, 
with different licenses, try to "rpmbuild -bs" (or -ba) the spec 
file, and you are building the package with the LICENSE file from 
another package due to the same LICENSE file getting overwritten 
4 times in SOURCES when they all got installed.

Ick Ick Ick.

The default RPM 'rpmbuild' configured directories just do not 
handle multiple src.rpm installations simultaneously in a safe 
way, nor do they handle multiple RPM packages being built at once 
simultaneously.  It also doesn't handle non-root builds, which is 
how everything should be build always with no exceptions (our 
entire OS has been built without using the root user for years).

While I think the best solution to this is a combination of 
things, one being to make rpm's shipped defaults more sane, I 
also understand that common practice is wide, and that would 
confuse people massively, and conflict with tonnes of 
pre-existing documentation, etc.

The best solution individual users or sysadmins setting up a 
machine for multiple users to build on can do, is to customize 
RPM's default configuration.  On a single user or smaller 
multiuser systems, simple per user config files is likely best.  
Each user having their own ~/.rpmrc and ~/.rpmmacros files which 
customize their rpmbuild environment to be in a per-user special 
location, per-project special location, or a common tree 
accessible to multiple users, but which solves the problems that 
the default rpmbuild environment installs which I described 
above.

For the single-user case, and for many other cases, I recommend 
my custom setup (duh, of course I do <grin>), which puts the 
default build heirarchy in ~/rpmbuild and creates dirs inside 
that named "BUILD" "SRPMS "RPMS" and "tmp".  The RPMS dir, is 
different from rpm's own dir of the same name, in that I've 
removed the per-architecture subdirs from it, so all binary rpms, 
regardless of architecture, land in the RPMS dir (personal 
preference).  The "tmp" dir, gets used for RPM_BUILD_ROOT and for 
rpm build time scripts.

When you install a src.rpm package, a new single directory is
created in ~/rpmbuild where the package is placed, named simply
enough "<name>-<version>".  Ie: I do my XFree86 development in
"~/rpmbuild/XFree86-4.3.0", which contains the spec file, all
patches, tarballs, and other junk from inside the src.rpm.  When
I compile the package, the src.rpm goes into the rpmbuild/SRPMS
dir, and all binaries, regardless of arch go into the
rpmbuild/RPMS dir.

That is the approach that I've personally settled upon over 3.5 
years which I've found works best for me, and was based loosely 
on suggestions from Jeff Johnson from ages ago, which have made 
rpm package development incredibly more productive and sane.

I've got a tarball with stuff in it for people to get started 
building rpms with this approach, with a similar config to mine, 
located at:

	ftp://people.redhat.com/mharris/hacks   rpmbuild-nonroot*

Many people love my default configuration, while some dislike it
or want to change it slightly to suit personal preferences of
their own, while some want to puke.

I welcome everyone to try it out, change it, modify it, laugh at
it, throw it away, pass it on to others, post slashdot articles
about it, burn it at the stake, mumble "my configuration is
better, mharris's sucks", puke, or whatever you like.

I hope people find it useful, either directly, or via
customization.  If anyone does download it and try it, please
read all documentation, and comments in files, etc. and if you
have problems/questions/etc. please do not email me directly as
I'm too busy to handle individual emails, and will probably not
do so, however email rpm-list at redhat.com for assistance
customizing it, and someone there will gladly help tweak.

Enjoy.


-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat