Re: DAK Commands for Bikesheds
On 14070 March 1977, Thomas Goirand wrote:
> I've carefully tried to make sense of the above commands to try to
> figure out what it would be for my own use case, which is one bs for
> each OpenStack release (one every 6 monthts), backported to whatever is
> the current stable.
> If I understand well, I'd do:
> Action: bikeshed-create
> Bikeshed: bs-openstack-liberty-jessie
> Description: OpenStack Liberty backport for Jessie
> Base-Suite: jessie
> Package: XXXXX
> Auto-Update: False
> I fail to see what one would put in Package, and what is the point of
> this. Why would one want to import a package from Sid in his Bikeshed,
> if the Bikeshed is already for Sid?
Without an auto-update, you get one version of a package - and get to
keep that. Even if it changes in the base suite.
With an auto-update you get the newest version (from the suite it came
from), always.
As Package is optional, you can happily create empty bikesheds.
With bikeshed-add and the addition of the suite option
to it, you can import packages even from another suite than the base
one, so a "my backport needs package foo from testing, no rebuild
needed" can be fulfilled without adding testing.
> For me, I'd continue to maintain OpenStack in Sid & Experimental, but I
> would also do backports uploaded to my Bikesheds. So I'm guessing that
> in this case, Base-Suite would be "jessie". But then, how would I import
> a package from the more generic "jessie-backports" to my Bikeshed?
Action: bikeshed-add
Bikeshed: bs--openstack-liberty-jessie
Package: mailfilter
Suite: bs-theoneandonly
I see that I wrote the doc for that in a way that it sounds pretty much
so that this can only import one package per bikeshed-add.
It probably should be able to import more than one in one run - but they
all have to come from the same suite.
> Also, once we have all the bikesheding in place (pun intended...), will
> we have some kind of apt command to add a Bikeshed?
Outside my area, but I sure hope so.
> I mean, something like "add-apt-repository ppa:FOO", but for
> Bikesheds? IMO, it would make a lot of sense to have something like
> /etc/apt/bikeshed.d, and a generic command like "apt bikeshed" (search
> (an online list of bikesheds) / list (what's installed in your system)
> / add / remove) to maintain this. I'd love to be able to do "apt
> bikeshed add openstack-liberty-jessie", or "apt bikeshed search
> openstack". How would apt get a list of bikesheds then? Will there be
> a Bikesheds.{gz,xz} available on our FTP mirrors? I suppose it doesn't
> make sense to have this in debian/dists, so maybe stored in
> debian/bikesheds? Then, will it be signed? With what key(s)? Maybe it
> would make sense to have a special key for the bikeshed list?
Having $whatever command is something I blindly assume will happen soon,
yes.
For data: There will be a human readable html overview, but also the
usual 822 style files with info about all bikesheds.
The whole key thing is an issue I have knowingly "pushed away" yet. We
have multiple options there. As the bikesheds all happen on the main
archive[1], with packages vetted by ftpmaster, same machine, we can
simply just go and use the standard archive keys.
The alternative would be a seperate key, just for the archive, and have
the 822 style file in the main mirror tree signed by the normal key, the
bikeshed archive and all its suite signed by the new key.
The only difference a new key currently would make would be that the
admin needs to add it - or have an updated debian-archive-keyring (or
debian-bikesheds-keyring) package installed. I don't see the win in
that - the admin has to do something manual to activate a bikeshed too,
asking for another key doesn't improve anything for them.
[1] If you reread the original specs, we talk about "external" too, a
second archive for them. That sure will come, but only after the
bikesheds here are full working. Now that sure will have extra keys,
possibly even one per bikeshed there.
--
bye, Joerg
<elmo> I'm James Troup, long term source of all evil in Debian. you may
know me from such debian-devel-announce gems as "Serious
Problems With ...."
Reply to: