Re: Can I interest anyone in RPM?

[Mark Eichin <eichin@cygnus.com>]

> I think we should at least explore the issue of using RPM/GLINT, etc.,
> as it's now become the clear standard packaging system for Linux - we
> are almost the only holdout. I know it's not as powerful as

Indeed, I've found that I need to package jade and other sgml stuff as
rpm's because my coworkers (at least the ones who need the sgml tools)
all use redhat (basically, the sysadmin who set the machines up in
that office got in with redhat first, and noone cared enough to change
it :-) rpm is certainly becoming a defacto standard *and* it's free
and more open than people thought it would be...

I could support a switch (to rpm, at least -- I don't care about the
higher level tools myself, but maybe that's due to aversion therapy, I
mean actually trying to use dselect a long time ago :-)  but there are
a few important considerations.  I've listed five here, as a starting
point, plus some examples of where rpm is ahead of dpkg.  We need to
discuss positioning/marketing/rationale *as well as* the technical
issues of doing a change like this.  We also need to get 2.0 out the
door first.

1) The RPM packaging tools and format need a *lot* of help.  A spec
file is basically a substituted, slice-and-diced, shell script, with
magic syntax marking things.  Fortunately they have variables now,
which makes it possible to avoid most repetition -- but they don't, as
far as I can tell, have *any* debmake-like tools...

fix 1: if we *ignore* the existing redhat packages, and simply migrate
the debian packages *including our helper programs* we probably win.

fix 1a: Even better, ignore the rpm SPEC approach, and just have
dpkg-deb --build produce rpms...

2) The RPM packaging "philosophy" is screwy.  The default arrangement
is that you do a make, make install, and then specify which files you
rip out of your installed system to shove in the package.  There is an
optional "BuildRoot" feature -- but because it's optional, it's not
safe to pick up a random package and say "build, then clean up after
yourself" because if it *didn't* use BuildRoot, it'll likely nuke your
whole system starting from /...

fix 2: see fix 1a.  Also, rpm *does* have an open development path
(via rpm.org) or at least it seems to (from comments from other people
here -- our sysadmins are attempting to use rpm to manage /usr/local
across a broad range of platforms, though they've really only got
solaris and sunos down right now...)  so we could be in a position to
actively push it the way we want to go.

3) rpm itself is kind of sad, compared to dpkg -- as far as I can
tell, you have to know upfront if you're installing or upgrading a
particular package, you can't just say "do the right thing" with it.
Also, it lacks a conflicts/replaces mechanism (conflicts is there, but
the auto-replacement features that make debian major upgrades go
*reasonably* smoothly seem to be missing.)  

fix 3: I think we can push on this one too, though I'm not quite sure
how, other than leveraging off the fact that we *do* a better job at
major upgrades than redhat has (redhat has gotten reamed in the press
about this before.)

4) we still need a value-add, to give people a reason to (1) use
debian (2) *work* on debian.  Do we want to use rpm as a package
format, but not use *any* of the redhat packages (though we would
support them at least as much as we do now via alien?)  That seems
like the high road, but I'm not inspired yet...

fix 4: doing a migration (fix 1a) should leave us with higher-quality
packages, and still let people mix in redhat packages; this quality
advantage might be enough.

5) rpm has a copyright: field which generally gets filled in with the
*license*, not the copyright; it's also only one line.  These are just
wrong and a fix needs to be rammed through.

Other notes:
	redhat is way ahead of us on "preserve original packaging".  A
specs file just lists, for example:
	Source: ftp://ftp.jclark.com/pub/jade/jade%{vermajor}_%{verminor}.zip
(the %{} macros are my attempt to set the versions *once* in the whole
file, they're not standard, but they work.)  Then the %prep section
begins with
	%setup -c -T
	unzip -a $RPM_SOURCE_DIR/${RPM_PACKAGE_NAME}%{vermajor}_%{verminor}.zip
Local changes are handled with
	Patch: jade.patch
(and possible patch1: and later lines, possibly conditionalized on
architecture...) The %prep section then simply has
	%patch -p1
after the above unzip line, and that takes care of it.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .