Re: support-snapshots.debian.org-in-live-build
On Wed, Jun 27, 2012 at 08:48:44PM +0200, Daniel Baumann wrote:
> On 06/27/2012 08:04 PM, Rui Miguel P. Bernardo wrote:
> > Following today irc talk here is a fresh patch against debian-next.
>
> thanks.
>
> > This removes the debian-snapshots mode and uses only standard options.
>
> much better this way.
>
> > Maybe --debian-snapshots true could be dropped and if
> > --debian-shapshots-date is set then use snapshots.debian.org?
>
> let's put aside the actual implementation details, and decide first on
> the interface and alogorithm.
>
> following your lead, i suggest to only add:
>
> --snapshot $DATE
>
Couldn't agree more, the boolean is redundant now.
> if snapshot is set to a date, then, by default (unless otherwise
> manually specified), the bootstrap, chroot, and binary mirrors are set
> to snapshot.debian.org for the corresponding date.
>
This is what I expect too.
> if d-i is supposed to be included, we'll try to get it from snapshot
> too, if there's none, we use the closest one we can find on the main
> archive.
This is the default in the patch, except with daily.
>
> if the users wants to have the main archive in the binary mirrors, he
> would need to specify them. i think this is better than to have the main
> archive by default
Yes, I expect that too. But don't dont forget the user will not be able
to run "apt-get update" out-of-the-box.
>, for three reasons:
>
> * personally, i would expect that if i create a 'snapshot' system, it
> will behave as if the clock was turned back, so, when i do an
> apt-get install foo on that system, it will fetch the historic
> package, and not try to (eventually) update the whole system to the
> current state.
Yes, that's what I would expect too;
>
> the action to update to the current state should be an action
> that, by default on such a snapshot, should be done explicitly
> (by changing apt sources), not implicitly (by apt-get dist-upgrade).
>
> otherwise, that seems to, by default, somewhat be against the
> purpose of such a snapshot system.
Yes, that would be the default. At build time the user still can use a
hook if he wants to do something like a "apt-get dist-upgrade" _if_ he
also changes the default "snapshot" sources.list _and_ handles the
"apt-get update" and apt.conf manually in the hook.
>
> * it's simpler to handle in live-build, and we don't need to deal with
> the fact that we don't want to upgrade the chroot after adding
> binary mirrors, and don't want to upgrade the auxiliary chroot that
> we use during chrooted builds.
>
Yes, as it's is the purpose of using snapshots.debian.org. Have a static
starting point and track that date by default.
> * it's more consistent with the specifying of the *-mirrors options
> with lb config.
>
> what do you think?
>
Yes, that is what I think too.
I tried to apply all that in the patch. The only thing that is not,
maybe, expected is when using the daily installer.
Because daily installer builds are not in snapshots.debian.org, and to
keep the same logic (to track by default the desired date), I make "lb
config" give error if daily installer is true but there is no daily
debian-installer in the desired date.
That is because daily installer builds are not always successfull _and_
the successfull builds are not preserved. They are removed periodically
using a criteria that I don't know. See the actual existing daily
installer builds today:
20110509-22:56/ 09-May-2011 22:56 -
20110930-00:25/ 30-Sep-2011 00:25 -
20111231-00:28/ 31-Dec-2011 00:28 -
20120101-00:32/ 01-Jan-2012 00:32 -
20120520-00:22/ 20-May-2012 00:22 -
20120622-00:17/ 22-Jun-2012 00:17 -
20120623-00:17/ 23-Jun-2012 00:17 -
20120624-00:20/ 24-Jun-2012 00:20 -
20120625-00:35/ 25-Jun-2012 00:35 -
20120626-00:16/ 26-Jun-2012 00:16 -
20120627-00:32/ 27-Jun-2012 00:32 -
daily/ 27-Jun-2012 00:32 -
Choosing the closest build for 20120301 would be hard and can lead to
kernel mismatch. That is why that, with daily installer, not all
snapshots are available and I check for it's existence when "lb config"
is issued and return an error if it doesn't.
But, as you said,
> let's put aside the actual implementation details, and decide first on
> the interface and alogorithm.
lb config -d squeeze --snapshot 20120601
would make a live image where built with the repos on that date and with
binary sources.list using that date snapshot repositories and not the
latest repos, right?
With installer, in squeeze, it will be easy to use an installer for
that date, because squeeze installer is in snapshots.
With daily installer, in wheezy, that is not so simple. My question is:
should we try to get the "closest" daily installer or give an error if
daily installer does not exist for that date?
The current live-build behaviour is to not warn the user and let the
build fail if no daily installer exists. That behaviour could be
preserved, but I hate when a build fails on that stage. But it may be
usefull to have the error at build time instead of config time" for some
reason, like check if everything else builds successfully, I just don't
like it because of the time I loose when it happens. The build is what
takes longer. Anyway, the exitence of daily installer may be dropped if
that is the desired behaviour.
Reply to: