[Date Prev][Date Next] [Thread Prev][Thread Next]
rpm package building as non-root (was: Re: src.rpm standards)
- From: "Mike A. Harris" <mharris redhat com>
- To: fedora-devel-list redhat com
- Subject: rpm package building as non-root (was: Re: src.rpm standards)
- Date: Thu, 29 Jan 2004 02:11:05 -0500 (EST)
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
>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
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
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
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,
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 redhat com for assistance
customizing it, and someone there will gladly help tweak.
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
[Date Prev][Date Next] [Thread Prev][Thread Next]