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.
Le 11 nov. 2014 19:03, "Pino Toscano" <ptoscano redhat com> a écrit :
> (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,
> - 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
> and you can find our Fedora-based appliances here:
> 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.