Re: Red Hat packaging (and hello all)

[Gregory Leblanc <gleblanc cu-portland edu>]

On 29 Apr 2001 16:28:39 -0500, David Elliott wrote:
> Hello,

Howdy!

> It's sad to say it, but RPM documentation is extremely poor.  Over the years
> I have picked up several things.  There needs to be a set of guidelines for
> gnome packages to ensure quality control and ease of installation.

This is right at the top of the list of things to do on the GPP projects
page.  :-)

> While everyone is focusing on binary packages, source packages are every bit
> as important.  I'll admit I am not very familiar with dpkg, but here are
> some things that definitely apply to RPM and might apply to DPKG.
> 
> 1. The packages should always be built as a non-root user.

Absolutely.  This means that you don't get stray files lying all over
your build system, and that building packages can't clobber anything
that you already have installed.  Any other reasons for this?

> 2. The source packages should be rebuildable with a simple rpm --rebuild
> package.src.rpm

We should also make this work from the source tarballs that are the way
that GNOME is really distributed.  Shouldn't be too hard, I've already
talked to quite a few hackers, and most have no objection to somebody
actually committing good spec files.

> 3. Packages must have appropriate Requires and even more important have
> appropriate Prereqs

Even more important than this is BuildRequires.  These are the packages
that are required to be installed when you issue an rpm command that
builds the binary packages from source.

> 4. Autoconf is great and all, but if a certain library is not available then
> package building should fail.  I cannot think of any specifics at the
> moment, but if a package is missing functionality because the system it was
> built on didn't have libfoo.so that is not a good thing.  Part of this
> involves maintaining configure.in and friends appropriately.

Right, BuildRequires is the correct solution to this.  I'm assuming that
dpkg has something similar, but I'll let the people who already know
debian worry about that.  

> 5. RPM supports relocating packages, it would be good to support this.  For
> example, it may be desirable to install a newer version of gnome packages
> into /opt/gnome to test it before going ahead and putting it in the standard
> /usr heirarchy.

Does anybody other than Jeff Johnson actually understand how this works?
I've read the stuff in Max RPM, and asked on the rpm list a couple of
times, but I still don't get it.  Aren't there some GNOME packages that
have paths hard-coded, and can't be moved?  

> 6. RPM scriptlets are just that, scriptLETS.  That is mini scripts.  The
> scriptlets should do the bare minimum for making the package run.  They
> should not reconfigure half of the system.  There is a huge difference in
> what is considered right and proper for a debian package to do and what is
> considered right for an RPM to do.  Debian has interactive configuration.
> RPM does not.  There should be absolutely no scriptlets that requires user
> input.  There should also not be any scriptlets that require user
> interaction after installation for the package to work correctly.

Right, we should try to stick with the established guidelines for
creating packages, no matter what our personal philosophy may be.  RPMs
are -not- installed interactively, that's all there is to it.  I don't
think that GNOME requires very many scripts to be run at all, outside of
'ldconfig', so this shouldn't be a big problem.

> 7. Try to maintain the users configuration as much as possible.  Red Hat's
> apache packages are bad about this (although it has a lot to do with the way
> apache's config file is one large file).

I don't know too much about this one offhand, but I seem to recall some
way of setting the behaviour for RPM so that files don't get clobbered
on install.  I just can't remember what it was.

> There are many more guidelines I am sure, but those are off the top of my
> head.  Most of these are actually my pet peeves with RPM packagers.

Well, we'll try not to peeve people with our packages.  :-)

> On a final note:  I love writing specs and working out the build process and
> designing really good packages, /BUT/ A 350 Mhz Pentium II is a bit slow at
> compiling gnome.  Given that as previously mentioned an 800 Mhz machine
> takes about a day to build gnome I would guess it would take my machine 2
> days.

Yeah, this sucks.  I've been thinking about how to solve this one a bit,
but I don't have a great solution, yet.  For our initial work, which
will be scripts or hand packaging, this machine just needs a metric
boatload of ram and disk, and a fast processor.  What I'd like to do is
set things up so that if we each have accounts on this machine, we're
not wasting too much disk space with 30 versions of the same source or
binary packages.  I just haven't figured out how to do that yet.  :-)

> Also, when building packages it often happens that you will have included an
> extra file in the files list or something stupid like that causing the past
> 2 hours of compiling to be lost because RPM will not package something that
> it did not build itself.
>
> To deal with this situation I generally do something like this in the
> package:
> 
> %if "%{fullbuild}" == "0"
> %{warn:YOU ARE A BASTARD. DON'T RELEASE THIS }
> %else
> %define fullbuild 1
> %endif

I don't have any idea what you're trying to do here, can you explain a
bit more?

> Okay, so maybe the warning is a bit harsh.  Fortunately after building one
> of these assuming you used -ba then you can do a --rebuild on the source
> RPM and thus you have killed two birds with one stone (1. You know that
> --rebuild works, and 2. You know that the package actually builds
> correctly).
> 
> Then you do something like this:
> 
> %prep
> %if ! %{fullbuild}
> %setup -D -T -n linux
> exit 0
> %endif
> %setup -q -n linux
> 
> The last line there is the usual %setup macro, the stuff in the %if block
> simply makes sure you are in the build directory for each section of the
> build process.
> 
> For the build section you want something like:
> %build
> %if ! %{fullbuild}
> exit 0
> %endif
> 
> Assuming you did something like:
> rpm -ba kernel.spec
> And then found out during the build that you needed to patch the source or
> you were missing files or something then you can do:
> rpm --define "fullbuild 0" -ba kernel.spec
> That is assuming you were already done building the whole thing and you just
> want to install and package it now.

I'm still not clear on what this accomplishes.  It looks to me like you
make it quit if you're not running a "full build".  I can't figure out
why you'd want to do that.

> Anyway, I am really looking forward to joining the packaging team!

Welcome!  We're certainly glad for more volunteers!
    Greg
    GPP Founder and Leader