incoming change to task handling in livecd-rootfs in mantic

[Michael Hudson-Doyle]

On Tue, 23 May 2023 at 03:34, Steve Langasek <steve.langasek at ubuntu.com>
wrote:

> On Mon, May 22, 2023 at 01:04:51PM +1200, Michael Hudson-Doyle wrote:
> > Thinking about this a bit more... what is germinate actually for in this
> > context? :-)
>
> > The way packages from a seed end up in an image goes like this at the
> > moment:
>
> > 1. it is listed in the seed
> > 2. germinate runs and puts the package and all its dependencies into a
> text
> > file
> > 3. live-build reads this text file and uses apt to install the packages
> > (4. we run mimimize-manual at some point so removing a seeded package and
> > running autoremove does something useful)
>
> > The thing about this is, *apt* obviously knows how to find the
> dependencies
> > of a package. Why don't we just shove the packages listed into the seed
> > straight into the file live-build reads?
>
> > (I suppose one answer might be to do with alternatives handling? cf
> > https://imgflip.com/i/7mmgcz -- does germinate do anything clever to
> > satisfy alternatives with a minimal number of extra packages or anything
> > like that?)
>
> It does not.  Indeed, several of the recent seed changes made while landing
> this were to fix the fact that germinate from livecd-rootfs (though not
> when
> run on the archive) was seeding two conflicting implementations one of
> which
> satisfies all the dependencies.




> (Actually this was a virtual package rather
> than an alternative, but AFAIK it doesn't do anything clever with
> alternatives either!)
>

Well potato potahto.


> I would expect feeding the list directly to apt rather than using germinate
> would result in some further changes to the exact packages included, which
> would then need to be examined to confirm they're what we want, since there
> are often multiple ways to resolve a seed.
>
> There's also the fact that you'd be reimplementing germinate's own parsing
> of the seeds and resolution of seed dependencies, so I'm not sure it's
> worth
> it?
>

Yes it's probably not worth it. But maybe we can lean this way for when we
implement things in ubuntu-image (although I think that has support for
running germinate already).

(One thing that would be nice, in addition to dropping the time-consuming
> use of germinate at runtime,


The slow part IME is downloading the package lists, the computational part
germinate only takes a few seconds.


> would be that today germinate silently ignores
> listed packages that are unavailable, whereas apt would enforce correctness
> of the list...)
>

That does sound like it would be an improvement.


> > ((Clearly we need something like germinate to generate the component
> > mismatches reports. But maybe not at image build time?))
>
> That's already run on ubuntu-archive-toolbox independently of the image
> builds, so would continue to do so.
>

Yes, I think my point here was that we can't just delete germinate
completely.

Cheers,
mwh


> --
> Steve Langasek                   Give me a lever long enough and a Free OS
> Debian Developer                   to set it on, and I can move the world.
> Ubuntu Developer                                   https://www.debian.org/
> slangasek at ubuntu.com                                     vorlon at debian.org
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20230523/63e2e030/attachment.html>