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(a)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