Re: DAK Commands for Bikesheds
On 14071 March 1977, Thomas Goirand wrote:
>> 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?
Wait, what, writing specs need use cases? :)
(Actually, finding such errors/wrong thoughts/all the interesting stuff
I forgot is what I wanted by posting this - and it worked out nicely so
far. I'm nearly done with the "support" work (rearranging some code in
dak) that had to be done before actually filling out my stub functions
for bikesheds - and the spec got much better. I like it. :) )
> 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.
There is an *option*.
Well, maybe that option doesn't make too much sense in the end. It does
(only) if you look at bikesheds as a seperate entity that can live
entirely without its base suite.
Or in a world where you have base-suite X, but let the bikeshed be built
against suite Y (say, auto-updating packages from testing, but
letting it build against stable).
Now, as I am not a buildd admin nor have there been deep technical
discussions with the buildd people (besides the "give us bikesheds and
we see about the buildd side" from DebConf), I've no idea if the latter
will be a supported config. I could imagine it, but bikeshed operations
will surely get more properties for that then. They are currently very
archive specific only.
>> 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.
Yup.
>> 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?
No. We have one key from the ftpmasters, which is used entirely
automagically, and we have the stable key, which is used entirely
manually by a different set of people.
And yes, we will be using the ftpmaster key or a new one with the "key
from the ftpmasters".
>> [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...
For the external ones that may end up being the case. For the bikesheds
now, I don't like the idea.
--
bye, Joerg
Reply to: