Re: DAK Commands for Bikesheds
On 09/20/2015 11:52 PM, Joerg Jaspert wrote:
> 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.
I did understand that, as you wrote it already. So I guess I didn't ask
for more explanation well enough. Let me try again then.
Why would I need to import a package? What's the use case? What I don't
understand is why would I create a new bikeshed with base-suite X, and
import a package from the same suite. Is the point to actually *freeze*
a package version? I don't believe so, as there's an option to
automatically update.
> 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.
Ok, got it. So for a backport bikeshed, I would initially create an
empty bikeshed.
> 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.
Yes, but as I remember, we have one key for stable and one key for
sid/testing, no? Should I assume we'd be using the sid/testing key?
> 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.
Right! And add some more work for maintaining this key.
> [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.
If the process of maintaining these keys is fully automated, why not...
Thanks for your answers,
Cheers,
Thomas Goirand (zigo)
Reply to: