Re: [gentoo-portage-dev] [RFC] Improving Gentoo package format

[Francesco Riosa]

Il giorno dom 11 nov 2018 alle ore 09:29 Michał Górny <mgorny@g.o>
ha scritto:

> On Sat, 2018-11-10 at 09:37 -0500, Alec Warner wrote:
> > On Sat, Nov 10, 2018 at 8:09 AM Michał Górny <mgorny@g.o> wrote:
> [...]
> > > My proposal
> > > ===========
> > >
> > > Basic format
> > > ------------
> > > The base of the format is a regular compressed tarball.  There's no
> junk
> > > appended to it but the metadata is stored inside it as
> > > /var/db/pkg/${PF}.  The contents are as compatible with the actual vdb
> > > format as possible.
> > >
> >
> > Just to clarify, you are suggesting we store the metadata inside the
> > contents of the binary package itself (e.g. where the other files that
> get
> > merged to the liveFS are?) What about collisions?
> >
> > E.g. I install 'machine-images/gentoo-disk-image-1.2.3' on a machine that
> > already has 'machine-images/gentoo-disk-image-1.2.3' installed, won't it
> > overwrite files in the VDB at qmerge time?
>
> Portage will obviously move the files out, and process them as metadata.
>  The idea is to precisely use a directory that can't be normally part
> of binary packages, so can't cause collisions with real files (even if
> they're very unlikely to ever happen).
>
> > > This has the following advantages:
> > >
> > > + Binary package is still stored as a single file.
> > >
> > > + It uses a standard compressed .tar format, with minimal
> customization.
> > >
> > > + The user can easily inspect and modify the packages with standard
> > > tools (tar and the compressor).
> > >
> > > + If we can maintain reasonable level of vdb compatibility, the user
> can
> > > even emergency-install a package without causing too much hassle (as it
> > > will be recorded in vdb); ideally Portage would detect this vdb entry
> > > and support fixing the install afterwards.
> > >
> >
> > I'm not certain this is really desired.
>
> Are you saying it's better that user emergency-installs a package
> without recording it in vdb, and ends up with mess of collisions
> and untracked files?
>
> Just because you don't like some use case doesn't mean it's not gonna
> happen.  Either you prepare for it and make the best of it, or you
> pretend it's not gonna happen and cause extra pain to users.
>
>
Another option would be to install in a near but not overlapping directory,
example:
/var/db/pkg/${PF}-binpkg

this way the user that know what to do with that data can play with it,
also portage could be instructed to stat() that directory and take action
(halt maybe?) if present.