Re: [Libguestfs] Add support for slackware in supermin

Le 11 nov. 2014 19:03, "Pino Toscano" <ptoscano(a)redhat.com&gt; 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/ 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.