Re: apt2ostree - build ostree images of apt based distributions



On Wed, 12 Dec 2018 at 18:57 Will Manley <will williammanley net> wrote:
On Wed, 12 Dec 2018, at 05:31, Daniel Drake wrote:
> On Tue, Dec 11, 2018 at 4:28 AM Colin Walters <walters verbum org> wrote:
> > Cool!  Would love if the deb-ostree-maintainers had a chance to look at this - there's a specific comparison here: https://github.com/stb-tester/apt2ostree#endless-ostree-builder-eob
>
> I imagine the deb-ostree-builder is lagging behind what we use
> internally, sorry about that.
> The comparison seems pretty accurate at a high level.
>
> However, in our updated internal version, we have stopped using
> debootstrap to set up the base filesystem tree. We got fed up of
> debootstrap acting differently from the real apt & dpkg
> implementations. We tried to fix it up, we tried to use multistrap too
> (same issue there), it just got too painful and instead of continually
> trying to adhere closer (and keep up with) apt, we decided to just use
> apt itself.
>
> If apt2ostree does not actually use apt for dep resolution, package
> installation etc, then I suspect it will ultimately face the same
> headaches.

Thanks for the heads-up.  Did you find the issues were more with apt dependency resolution and package selection, or more on the installation/dpkg side or both?

I've been thinking about the topic a bit, and I've come to a few conclusions:

* There's no reason not to use apt for dependency resolution. As I understand, debootstrap only doesn't so it doesn't depend on Debian-specific things.
* You want to be able to unpack every package in isolation so you can commit them into OSTree individually.
* You probably can't run any preinst scripts. This is because you need either a (partial) filesystem tree (if it's a shell script) or binary emulation (if it's compiled, as is e.g. the case for the dash package). In general, it seems to me that running package code during the unpack phase is probably out of the question.
* If you don't want to run preinst, you can't use "dpkg --unpack" because that's not a valid package state. Installing a package manually isn't actually that difficult (I have a prototype that simply copies what multistrap does) but you have to tie yourself to the dpkg database format.

I don't see a way to cleanly deal with the preinst thing. "Not running preinst" has been working fine for multistrap, but I suspect it'll break packages that do fancy diverting in their preinst. I've been going on the assumption that that's ok, but if it's not, things get messier.

-Felix


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]