Re: A GNU Distribution

[Claudio Fontana]

On Tue, Apr 10, 2012 at 11:54 AM, Brandon Invergo <address@hidden> 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