Libguestfs - Nov 2014 - Re: Add support for slackware in supermin

What I was suggesting, is to let the user manage depencies himself.

This is what slackware users are used to do anyway.

It means that we should be able to provide an exhaustive list of needed
packages on the command line.

As the semantic differ from the usual treatment of the PACKAGES arguments
of supermin --prepare, this could be managed by a new option implying "do
not search or install depencies for the given packages".

What do you think ?
Le 11 nov. 2014 18:19, "Pino Toscano" <ptoscano@redhat.com> a
écrit :
> Hi,
>
> On Tuesday 11 November 2014 15:23:40 Mathieu Bouillaguet wrote:
> > Hi Pino,
> >
> > Thanks for your reply and details.
> >
> > I started looking at the others package manager code and as I see it
> > there is one main problem to port supermin to slackware distro.
> >
> > Slackware builtin package management tools (pkgtool and slackpkg) do
> > not manage package dependencies. There is no easy solution to solve
> > this problem.
> > There are third party packet manager which manage dependencies but
> > they are not supported and I don't personnaly use it.
> >
> > It would be possible to make supermin install only the packages
> > entered on the command line by the user for slackware distro but
> > maybe other tools rely on the package dependency installation
> > semantic.
>
> supermin relies on a package manager to provide the basic information,
> including its dependencies and the list of its files. It needs such
> information to be able to install in the supermin appliance that it
> creates all the packages specified, including all of its dependencies
> (recursively); this way it is possible to pull all the package needed,
> making sure the appliance can run.
>
> Imagine I want to build an appliance with bash, gcc, make, and a
> library, so I can build in a clean environment with that library:
> supermin needs to pick those packages in the appliance, together with
> all the packages needed by those. That's how supermin works, basically.
>
> If slackware does not provide basic package management like that, I'm
> not sure how supermin is supposed to work.
>
> --
> Pino Toscano
>

Hi,

(please do not top-reply...)

On Tuesday 11 November 2014 18:32:10 Mathieu Bouillaguet
wrote:
> What I was suggesting, is to let the user manage depencies himself.
> 
> This is what slackware users are used to do anyway.
> 
> It means that we should be able to provide an exhaustive list of
> needed packages on the command line.
> 
> As the semantic differ from the usual treatment of the PACKAGES
> arguments of supermin --prepare, this could be managed by a new
> option implying "do not search or install depencies for the given
> packages".
> 
> What do you think ?
What you are suggesting covers just one of the requirements of supermin 
for the package manager. The others, which I wrote in a previous email, 
are:
- query name, version, epoch (if existing), architecture of a package
- get the last "change time" of the package manager
- get the file list of a package (possibly with the information about
  which ones are "configuration files")
- download a package

What supermin needs seems not met by the too limited package management 
on slackware, I'm afraid.

On the other hand, this does not imply you cannot use libguestfs: with a 
driver-less supermin, you can build libguestfs without an appliance
(--disable-appliance), and use a "fixed appliance", i.e. an appliance 
built on a different system, pointing libguestfs to it. See also 
"LIBGUESTFS_PATH" in
  http://libguestfs.org/guestfs.3.html#environment-variables
and you can find our Fedora-based appliances here:
  http://libguestfs.org/download/binaries/appliance/

-- 
Pino Toscano

Sorry for the top posting, it's the gmail app behavior.

It didn't mention the other aspects because they are not a problem. The
only "problem" is the package depency.

Cordially
Le 11 nov. 2014 19:03, "Pino Toscano" <ptoscano@redhat.com> a
écrit :
>
> Hi,
>
> (please do not top-reply...)
>
> On Tuesday 11 November 2014 18:32:10 Mathieu Bouillaguet wrote:
> > What I was suggesting, is to let the user manage depencies himself.
> >
> > This is what slackware users are used to do anyway.
> >
> > It means that we should be able to provide an exhaustive list of
> > needed packages on the command line.
> >
> > As the semantic differ from the usual treatment of the PACKAGES
> > arguments of supermin --prepare, this could be managed by a new
> > option implying "do not search or install depencies for the given
> > packages".
> >
> > What do you think ?
>
> What you are suggesting covers just one of the requirements of supermin
> for the package manager. The others, which I wrote in a previous email,
> are:
> - query name, version, epoch (if existing), architecture of a package
> - get the last "change time" of the package manager
> - get the file list of a package (possibly with the information about
>   which ones are "configuration files")
> - download a package
>
> What supermin needs seems not met by the too limited package management
> on slackware, I'm afraid.
>
> On the other hand, this does not imply you cannot use libguestfs: with a
> driver-less supermin, you can build libguestfs without an appliance
> (--disable-appliance), and use a "fixed appliance", i.e. an
appliance
> built on a different system, pointing libguestfs to it. See also
> "LIBGUESTFS_PATH" in
>   http://libguestfs.org/guestfs.3.html#environment-variables
> and you can find our Fedora-based appliances here:
>   http://libguestfs.org/download/binaries/appliance/
>
> --
> Pino Toscano
Sorry for the top posting, it's the default gmail app behavior.

It didn't mention the other aspects because they are not a problem for a
slackware port. The only "problem" is the package depency.

Cordially