[WBEL-devel] Package Keys

[ramblings@sadlittleboy.com]

Personally, I'd be against this unless A) redhat is doing it and B) it
really appears to offer significant value (eg fixes ability to install in
certain popular machines, and floppy install or driver disk isn't a
solution for them, or WBEL is going to be sued otherwise, etc).  The reason
I generally oppose this is that it makes life harder for not only the
maintainer, but also wastes space on the mirrors who often keep copies of
each "release" version.  At least, that's the way most of the RedHat
mirrors work FWICT.  Probably the mirrors will change behaviour for fedora
(since it has insanely frequent releases), but I still feel that it isn't
the right way to go.  If RedHat does release maintanence versions (3.1 etc)
then fine, maybe we should do so as well, but otherwise I think not.

That being said, I don't see anything wrong with a periodically released
"contrib" disk, maybe that even has new packages or boot options if that's
possible, (is it possible to add a pre-disk1 cd that overrides packages on
other cds?) but it should be maintained separately and packages should be
signed with a contrib key, etc.  I'm saying to use a different key so that
nobody is confused and installs a contrib package when they really want the
"stable" version.

On 12:01:00 am 12/17/03 Ryan Finnie <ryan@finnie.org> wrote:
> On Tue, 16 Dec 2003, John Morris wrote:
> >  Of course WBEL's up2date is importing the WB key even though the
> >  dialog still says RH.  Yea, I know.  Didn't notice it till it would
> >  have been a major PITA to restart the build process.  Next update.
>
> So now that -final is "out" (shhhh, don't tell anyone until the official
> announcement), I assume all little fixes like these will become available
> as WBEL-supplied errata?
>
> Also, I know this is a long way down the road, but how about doing a
> "rollup" release once per year over the course of red hat's 5-year
> support cycle?
>
> RF