From herrold@owlriver.com Tue Feb 18 10:09:55 2003
Date: Thu, 14 Nov 2002 10:31:21 -0500 (EST)
From: R P Herrold <herrold@owlriver.com>
To: rpm-list@freshrpms.net
Subject: Re: f-rpm] RFC - Fedora Community Proposal

-----BEGIN PGP SIGNED MESSAGE-----

On Mon, 11 Nov 2002, Warren Togami wrote:

> http://videl.ics.hawaii.edu/~warren/fedora.html
> 
> This is a request for comments about the "Fedora Community Proposal" 
> that I have written at this address.  Fedora is my draft proposal for a 
> formalized Debian-like network of a RH package community.  Suggestions, 
> comments and/or constructive criticsm is welcomed.

Thanks for the obvious effort and thoughtfullness, Warren.  I
pulled, printed and have read it a couple times upon your
announcement.  In between, I have been thinking about it.  I
wonder at the cast tied to the Red Hat distribution releases
alone.  

Fedora is cute as a name, but there is an 'I hate everything
Red Hat' wing in Linux, even within RPM using distriburions --
Watch Cooker list for a post by me touching on this later
today.

Really and truly, from _my_ prespective, it would be much more
likely to succeed as a vendor neutral SRPMS archive.  

Also it provides a locus to rationalize (or at least compile)  
vendor specific local .rpmrc macros library to permit
'translation' of local variances those macros.

Finally, then, a local maintainer would have an autobuilder
pull and build SRPMs -- I think Gregory Leblanc mentioned
one yesterday here; I have had one for years which just walks
SRPM archives, decides if the SRPM found is later than the
built tree, and if so, builds it as non-root.  It's not very 
smart and burns cycles -- but why not if the host is powered 
for other purposes, anyway?

The distro/version/arch sub-maintainer would run this
background tool against a mirror of just the SRPM branch of
the archive, review the build error log, file Bugzila reports
with the upstream SRPM packager (a quasi-maintainer).  Oh,
yeah -- if it built cleanly, the The distro/version/arch
sub-maintainer would sign and place a binary RPM in a place it
could migrate to the central (in this case arch, vendor and
release tree'd) master mirror.

[ESR had a proposal for a distributed mirror/indexing system
called 'trove' a few years -- a variation on this may permit
solving rights for getting signed content into a central
master mirror]

A convergence to permit reasonably distribution neutral
packaging of sources, patches, all wrapped up in RPM .spec
files, using the LSB compatability libraries and LHS layout,
permit such a project to be less RH 'parochial', and of more 
general interest.

I know it can be done -- my public packagings at
   ftp://ftp.owlriver.com/pub/local/ORC/ 
demonstate that -- about 400M of 'stuff' I needed/wanted, not 
in the major distros in the form I liked.  I regularly pull, 
package and rebuild from all over Unix-dom as well as just 
Linux-dom --

My $0.02

- -- Russ Herrold

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBPdPB0GS3OKZ7+5i5AQHymwQAzHCjhl5ohfr06Atqp7/AtoiECUyzsLqe
ji5oVnOH5IJcTCEVbcL3w6DJqMS8PT/5D/+O1A4wPZtqxshpheGNIcfsB3+WuUTf
sBToF8x4uZxRa0pRBtOTcaNBijvtN5z7o3zXiUpfmLJeba6w/KDkJJJ+xNkRZBEC
6UmuZ3US6j4=
=AW0u
-----END PGP SIGNATURE-----