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

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.

What is your opinion about this ? How supermin is used by other tools like
libguestfs ?

Thanks for your reply

Mathieu
 Le 10 nov. 2014 19:06, "Pino Toscano" <ptoscano@redhat.com> a
écrit :
> Hi Mathieu,
>
> On Sunday 09 November 2014 16:14:32 Richard W.M. Jones wrote:
> > On Sat, Nov 08, 2014 at 02:27:49PM +0100, Mathieu Bouillaguet wrote:
> > > Hi,
> > >
> > > What needs to be implemented to add support for slackware
> > > distribution in supermin ?
> >
> > hi Mathieu
> >
> > I'm on holiday at the moment and will give a more complete reply
> > when I get back.  In brief you need to be able to do a few simple
> > package database meta operations such as listing all files in a
> > package and listing the installed deps of a named pkg.  This pre-
> > supposes that slackware has such a packaging db.  Pino CCd can
> > give more details, and you can look at existing pkg systems in
> > src/*.ml.
>
> As Rich said briefly, supermin needs to be taught about the package
> manager running on Slackware.  supermin needs it to perform some
> operations on the system, such as:
> - query the basic information about a package (name, version, and all
>   the basic attributes such as epoch and architecture, if present/needed
>   to unequivocally identify a package later) given its name
> - get the last time the package system has "changed" (like after
an
>   update, or having installed/removed some package); this is needed so
>   supermin can avoid querying the package system when the set of
>   installed packages has not changed since last time supermin was run
> - get the list of dependencies of a package
> - get the list of files of a package, marking whether a file is
>   considered "configuration file" by the package manager; usually
this
>   is the case for files in /etc, which the admin can edit, and the
>   package manager carefully handles when updating packages providing
>   them
> - download and extract packages from the sources of the package manager;
>   this is needed so supermin can pick pristine copies of the files of an
>   installed package, usually to have unedited configuration files
>
> supermin supports already few package manager, and you can find in the
> src/ subdirectory their implementations: dpkg.ml, pacman.ml, rpm.ml.
>
> --
> Pino Toscano
>

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

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
>

On Tue, Nov 11, 2014 at 03:23:40PM +0100, 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.
> 
> What is your opinion about this ? How supermin is used by other tools like
> libguestfs ?
>From a libguestfs p.o.v it'll be fine to list all packages needed (ie
including dependencies) in libguestfs.git/appliance/packagelist.in.
That should mean that the complete list of packages is passed to
supermin on the cmdline, so the supermin slackware dependency resolver
can be a no-op.

Rich.
> Thanks for your reply
> 
> Mathieu
>  Le 10 nov. 2014 19:06, "Pino Toscano"
<ptoscano@redhat.com> a écrit :
> 
> > Hi Mathieu,
> >
> > On Sunday 09 November 2014 16:14:32 Richard W.M. Jones wrote:
> > > On Sat, Nov 08, 2014 at 02:27:49PM +0100, Mathieu Bouillaguet
wrote:
> > > > Hi,
> > > >
> > > > What needs to be implemented to add support for slackware
> > > > distribution in supermin ?
> > >
> > > hi Mathieu
> > >
> > > I'm on holiday at the moment and will give a more complete
reply
> > > when I get back.  In brief you need to be able to do a few simple
> > > package database meta operations such as listing all files in a
> > > package and listing the installed deps of a named pkg.  This pre-
> > > supposes that slackware has such a packaging db.  Pino CCd can
> > > give more details, and you can look at existing pkg systems in
> > > src/*.ml.
> >
> > As Rich said briefly, supermin needs to be taught about the package
> > manager running on Slackware.  supermin needs it to perform some
> > operations on the system, such as:
> > - query the basic information about a package (name, version, and all
> >   the basic attributes such as epoch and architecture, if
present/needed
> >   to unequivocally identify a package later) given its name
> > - get the last time the package system has "changed" (like
after an
> >   update, or having installed/removed some package); this is needed so
> >   supermin can avoid querying the package system when the set of
> >   installed packages has not changed since last time supermin was run
> > - get the list of dependencies of a package
> > - get the list of files of a package, marking whether a file is
> >   considered "configuration file" by the package manager;
usually this
> >   is the case for files in /etc, which the admin can edit, and the
> >   package manager carefully handles when updating packages providing
> >   them
> > - download and extract packages from the sources of the package
manager;
> >   this is needed so supermin can pick pristine copies of the files of
an
> >   installed package, usually to have unedited configuration files
> >
> > supermin supports already few package manager, and you can find in the
> > src/ subdirectory their implementations: dpkg.ml, pacman.ml, rpm.ml.
> >
> > --
> > Pino Toscano
> >
-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

On Tue, Nov 11, 2014 at 06:41:40PM +0000, Richard W.M. Jones
wrote:
> On Tue, Nov 11, 2014 at 03:23:40PM +0100, 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.
> > 
> > What is your opinion about this ? How supermin is used by other tools
like
> > libguestfs ?
> 
> From a libguestfs p.o.v it'll be fine to list all packages needed (ie
> including dependencies) in libguestfs.git/appliance/packagelist.in.
> That should mean that the complete list of packages is passed to
> supermin on the cmdline, so the supermin slackware dependency resolver
> can be a no-op.
Reading further in the thread - I agree with Pino that this is not
ideal.  It would be better to have the package manager db store deps.
But I don't have any problems with a big list in libguestfs
packagelist.in (defended by `if SLACKWARE ...')

Rich.
> Rich.
> 
> > Thanks for your reply
> > 
> > Mathieu
> >  Le 10 nov. 2014 19:06, "Pino Toscano"
<ptoscano@redhat.com> a écrit :
> > 
> > > Hi Mathieu,
> > >
> > > On Sunday 09 November 2014 16:14:32 Richard W.M. Jones wrote:
> > > > On Sat, Nov 08, 2014 at 02:27:49PM +0100, Mathieu
Bouillaguet wrote:
> > > > > Hi,
> > > > >
> > > > > What needs to be implemented to add support for
slackware
> > > > > distribution in supermin ?
> > > >
> > > > hi Mathieu
> > > >
> > > > I'm on holiday at the moment and will give a more
complete reply
> > > > when I get back.  In brief you need to be able to do a few
simple
> > > > package database meta operations such as listing all files
in a
> > > > package and listing the installed deps of a named pkg.  This
pre-
> > > > supposes that slackware has such a packaging db.  Pino CCd
can
> > > > give more details, and you can look at existing pkg systems
in
> > > > src/*.ml.
> > >
> > > As Rich said briefly, supermin needs to be taught about the
package
> > > manager running on Slackware.  supermin needs it to perform some
> > > operations on the system, such as:
> > > - query the basic information about a package (name, version, and
all
> > >   the basic attributes such as epoch and architecture, if
present/needed
> > >   to unequivocally identify a package later) given its name
> > > - get the last time the package system has "changed"
(like after an
> > >   update, or having installed/removed some package); this is
needed so
> > >   supermin can avoid querying the package system when the set of
> > >   installed packages has not changed since last time supermin was
run
> > > - get the list of dependencies of a package
> > > - get the list of files of a package, marking whether a file is
> > >   considered "configuration file" by the package
manager; usually this
> > >   is the case for files in /etc, which the admin can edit, and
the
> > >   package manager carefully handles when updating packages
providing
> > >   them
> > > - download and extract packages from the sources of the package
manager;
> > >   this is needed so supermin can pick pristine copies of the
files of an
> > >   installed package, usually to have unedited configuration files
> > >
> > > supermin supports already few package manager, and you can find
in the
> > > src/ subdirectory their implementations: dpkg.ml, pacman.ml,
rpm.ml.
> > >
> > > --
> > > Pino Toscano
> > >
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html
> 
> _______________________________________________
> Libguestfs mailing list
> Libguestfs@redhat.com
> https://www.redhat.com/mailman/listinfo/libguestfs
-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW