On Tue, Apr 10, 2012 at 11:54 AM, Brandon Invergo <[email protected]> wrote: >> With regards to the GUI, I did something of partly overlapping scope >> in the past with the sourceinstall project; >> >> http://www.gnu.org/software/sourceinstall/ >> > > There does seem to be a lot of overlap in functionality there, though > the backend looks like it functions quite differently. How does one use > it? Is the source downloaded manually by the user and then installed via > the software? Or can the program search some repository of available > software packages and automate the downloading and unpacking?
There is overlapping but it is also different. The goal of sourceinstall is to be able to install arbitrary source packages from source code, with no repository in mind, and is not meant to be bound to a particular OS. For my use case, I keep my OS packages in prefix /usr, while I use sourceinstall to install packages from source code into /usr/local. So yes, the user downloads manually a source package, or checks out a source tree from a repo, then launches the installer on that package. It works for me and the class of users like me, but is not exactly the target of an installer for the whole GNU system. The user chooses a source directory (for example a CVS directory), or a source package (for example in .tar.gz format), and the program helps with doing the configuration and installation of the source package, keeping track of installed files, and optionally keeping the already configured source code, along with all configure options used during the build. It then provides some additional functionality like safer uninstallation, upgrade etc, by leveraging the information about each packages' installed files. >> I understand that what is needed needs to be more scriptable, and in that >> sense, >> maybe a bash glue should be built first (by someone who understands >> the underlying tools better), >> and then I could rewrite/reuse/repurpose the GTK GUI to work on top of >> either that glue script >> or be an alternative, graphical implementation of the glue script. >> >> So if you have something concrete below to rely on, I can do the more >> or less "dumb" GUI work. > > I agree that the Bash glue code should be written first, at the very > least in order to prototype the full package management process. I have > a decent amount of experience with GTK but mostly in Python. I can hack > together at least an initial version fairly quickly. At the moment, > though, much of my time is dedicated to bringing the GSRC repository of > Makefiles up-to-date (it went unmaintained for some time). > > As an alternative, there is PackageKit [1] (GPLv2) for which Gnome > already has a front-end [2]. It would just be a matter of building a > back-end to the package management system we develop via PackageKit's > so-called "Spawned Backend" system [3]. This spawned backend could be > written in, say, Bash and act as the "Bash glue script" that we've > previously mentioned, making calls to GSRC, Stow, etc as needed. The > user would only need to either use the Gnome GUI frontend or > PackageKit's commandline tool [4] to manage software. The package > management system that we write doesn't need to implement all of the > functionality covered by the PK software; our backend would "advertise" > the functionality that it covers to PK, and PK would adjust the > front-ends to accomodate the functionality that exists while hiding any > functionality that we don't provide. > > Regards, > Brandon > > > [1] http://www.packagekit.org > [2] http://www.packagekit.org/pk-screenshots.html#gnome > [3] http://www.packagekit.org/gtk-doc/backend-spawn.html > [4] http://www.packagekit.org/pk-using.html This packagekit seems interesting but fairly (unnecessarily) complicated to me, and tightly bound to the whole gnome set of dependencies. Is not necessarily a bad thing, just not my personal cup of tea. Also, I am more efficient with C/GTK than with python/pygtk, so if you want the GUI to be in python, I cannot help much. I guess the question is if you want the system to be only usable in the context of a whole, tightly controlled system (like for example the Debian or Ubuntu or Red Hat repositories + tools), or if you want to enable users of other arbitrary systems to make use of the GNU source-based package system as well. In the second case, it should be better to cut down on dependencies even for the GUI (nowadays one can assume GTK on desktop GNU/Linux systems is present, while I would not assume gnome is available). In the first case, you are free to assume whatever is distributed with the GNU desktop system is available. Cheers, Claudio
