Re: debian.kernel.net archive for security updates & other stuff
On Wed, 2005-10-19 at 11:53 +0200, Sven Luther wrote:
> On Thu, Oct 06, 2005 at 07:37:36PM -0600, dann frazier wrote:
> > Unified Repository for Proposed Kernel Security Updates
> > -------------------------------------------------------
> > I've created a unified archive for our proposed security updates for
> > sarge. Hopefully this will make it easier for users to test/use these
> > builds, as well as provide a single location for the security team to
> > pick them up.
>
> Hi Dann,
>
> This is indeed great news.
>
> > This archive will soon be available at:
> > deb http://kernel.debian.net/debian sarge/updates main
>
> I would like that we use kernel.debian.org instead of .net, which makes it
> more official. This was also proposed to me by the web/net/whatever guys in
> hel, if i remember well, so we can easily and legitimately use it.
kernel.debian.net makes more sense to me as i associate .net with
development type projects, versus something for everyone that we support
for all debian users. If we're distributing packages that aren't on
*.debian.org (updates that haven't moved to security.debian.org,
proposed sarge updates that haven't been approved, etc), then it doesn't
feel very .org to me. Consider volatile.debian.net, for example.
But really the above statement is an afterthought.
To be honest, 99% of the reason I chose .net instead of .org is that I
can make that happen immediately without convincing anyone else - .org
domains probably require some amount of politicing (snapshot,
anyone?).
If others on the team would prefer .org, I'm cool with that, as long as
it can happen w/o a flamewar on -project/-private/etc. This archive
isn't intended to disparage backports.org, volatile.debian.net,
security.debian.org, etc, but some people might take it that way.
> > But until alioth has the alias configured, use kernel.alioth.debian.org
> > instead. The debian.net url should give us more flexibility should we
> > decide to relocate the archive at some point.
> >
> > Please let me know soon if there's anything you'd like to see changed.
> > I'd like to announce this more broadly RSN. (For instance, should the
> > dist be sarge/updates? Maybe sarge-proposed-updates or sarge-security?)
>
> I would vote for both sarge security and some kind of sarge backports or
> something, since it is becoming clearer that volatile is not the place for
> those kernel backports we created, and backport.org has a different focus.
The beauty of using alioth is that everyone in the kernel team has
permission to modify this archive. Feel free to start subprojects for
backports, etc, just be sure to use a good descriptive dist name.
Speaking of which, I think I'll change my existing one from sarge to
sarge-proposed-security; that is more accurate.
> > Managing the Archive
> > --------------------
> > I've created a simple archive management system to hopefully make it
> > easy/efficient to manage. It sits in the root of the archive tree:
> > alioth.debian.org:/org/alioth.debian.org/chroot/home/groups/kernel/htdocs/debian
> >
> > The contents of each dist is maintained in a 'pkglist' file.
> > (sarge/updates is the only dist at the moment). pkglist files just
> > contain a list of .changes files to include. A toplevel Makefile
> > processes these files, creates the dists/ hierarchy, and finally runs
> > apt-ftparchive generate.
> >
> > This should make it easy to quickly add dists and share packages between
> > them. Say, sarge-proposed-updates or sarge-backports. (Not that we
> > shouldn't use backports.org or volatile where appropriate, of course).
> > We could store these pkglists in svn at some point, should we want
> > revision control on the archive.
>
> Seems a great plan, thanks for doing it, i will try to do a 2.6.14-rc4 sarge
> backport including all related packages (kernel-package, udev,
> initramfs-tools, initrd-tools, yaird, what else), in the next time.
cool
> We have no autobuilder setup for this yet though, which would be cool to have,
> have you thought of that, or maybe there is a possibility to share one of the
> other autobuilder networks (main, experimental, volatile, not sure how it all
> works), or roll our own (i would gladly setup a powerpc autobuilder for this
> archive, altough we can also use the augsbourg machines).
I hadn't thought about it, no. I don't have any good ideas on the
subject either.
> This would also be the best place to hold not-yet-ready-for-unstable packages,
> as i feel the experimental uploads where not all that satisfactory.
Well, experimental is autobuilt.. though not on many archs evidently :(
Other than that, I agree - I'd prefer to use this instead.
Reply to: