"the rpm question" - summary

[Lamar Owen]

On Saturday 08 November 2003 07:21 pm, Warren Togami wrote:
> On Sat, 2003-11-08 at 12:12, Ingo T. Storm wrote:
> > I think it all comes down to D, which is rather about opinion and
> > directions than technical fact and touches an important question: How
> > much _Fedora.us_ is in _FedoraLegacy_? To me it looks like it's rather
> > the "Fedora.us" core people would like to stay on a successful track
> > (same rpm for everyone),

> 2) I never advocated upgrading to the same version of rpm, rpm-4.2 was
> mentioned.  I mentioned that the latest upgrade to the latest versions
> rpm-4.2.1, rpm-4.1.1 and rpm-4.0.5 at rpm.org.

For what it's worth, on a purely technical point, Red Hat already did this in 
the past.  It is not unreasonable to get everyone up to the same spec file 
behavior so that the updated RPMs can be more easily maintained.  I have had 
to maintain specs that build on more than one RPM version.  I even had to 
once do this with as old an RPM version as 2.5.

So, Ingo, there are valid technical reasons to desire the same RPM version 
across the board, if it's not technically unfeasible to do so.  Now, if it is 
technically unfeasible, then that's a different issue.  But there's no 
politics involved from my view: not that there isn't from others; I can only 
vouch for my own opinion.

As to the the politics, I have only two words to the 'opposing factions' 
involved.  "Grow Up!"

Fedora Legacy won't involve third party repositories, fancy release tags, or 
any such.  There is strong precedent in the package naming of previous 
errata; this precedent should continue to be followed so that upgrades don't 
break from a up2date 7.3 to Fedora Core (or even to RHL9, for that matter).  
So the issues here are much fewer than the current maelstrom over on the 
Fedora lists.  The issues here are not the same as even the old fedora.us 
issues, so the same guidelines don't necessarily need to apply.  If anything, 
the guidelines might need to be stricter.

I see:
1.)	A package needs a maintainer.  This is not a small task for some packages: 
for instance, if a security alert happens for PostgreSQL, the erratum needs 
to be for the same major version as shipped with that supported Red Hat 
release.  (I pick on PostgreSQL since I maintain the postgresql.org RPMset).  
This task for PostgreSQL may mean a major backpatching effort (which happened 
not long ago for multiple releases where the upstream developers were not 
wont to backpatch).  This would have to be up to the maintainer to do, 
though.  The maintainer must be able to exercise some authority over the 
owned package; rely on the maintainer's possessiveness to keep things right 
and tight, within guidelines.  This is not unlike how Red Hat works 
internally, from what I've gathered in four years of beta testing.

2.)	Guidelines for how to go about the above.  When does it become 
unreasonable to stay with the same major version, backpatching security 
fixes?  Red Hat did this; this is very resource intensive and is expensive, 
which is why we are in the whole Fedora Legacy situation in the first place.

3.)	There needs to be a good way to get the updates out to users.  This 
implies a trust infrastructure between developers, as well as a mirror 
structure and secure uploading mechanisms.  A simple way to do this is with 
scp using RSA authentication.  The upload needs to be source only -- the 
buildfarm needs to build and sign with the Fedora Legacy key in an automated 
(or semi automated for a little extra security -- I have some ideas how to 
make this secure and not exploitable -- the biggest thing is that the actual 
build farm must not be directly connected to the Internet) fashion.  This 
simplifies the trust relationship somewhat, since the binaries are all signed 
with a single key (or at least a few keys, instead of one for each 
maintainer).   This boils down to the question 'How seriously is Fedora 
Legacy going to take itself?' -- that is, is FL going to be a volunteer 
business with a security reputation equal to Red Hat's (I personally think 
this is unreasonable: the only way I'm going to use community-built errata is 
by rebuilding from source RPM!). (although I break my own rules with the 
Aurora project, but that's about to change...)  Or to put it much more 
bluntly: I wouldn't even install the PostgreSQL binaries that I myself upload 
on my production machines.  And it has nothing to do with the fact that they 
are not signed.

4.)	There needs to be some governance.  I propose a steering committee based 
on merit: if you put up the bandwidth, you get a say in the governance, etc.  
This is the way the PostgreSQL steering committee works.  Membership is by 
invitation of the existing steering committee.  Those who do the work get a 
say in how the work is done, basically.  This would be the way rogue 
maintainers would be reigned in. (revoke their RSA auth keys, no login).  
There must be checks and balances all the way around.  A dictatorship is 
worse than anarchy, but neither are very productive.

5.)	If FL is to be taken seriously by people like me (IT Directors), then the 
petty squabbling must stop.  Now.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu