goodies-management

[Brian J. Tarricone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nicolas Masse wrote:
> On Mon, 15 Aug 2005 12:15:49 -0700 "Brian J. Tarricone"
> <bjt23 at cornell.edu> wrote:
>
>> I haven't finished reading the entire thread, so this may be menioned
>>  elsewhere, but in my mind, this isn't enough.  There needs to be a 
>> mechanism to download and install precompiled packages (whether
>> they're .debs, RPMs, Solaris pkgs, etc.).  It seems to me that the
>> whole point of this goodies manager is to make it easier on newbies
>> and "average joes" to learn about other available packages and
>> install them easily. We can't assume they have a full set of compiler
>> tools and the appropriate -devel packages installed.
>> 
>> This can, of course, be done in steps.  Implement the
>> build-from-source option only, but design the ability to list and
>> install binary packages into the XML format, something like this:
>> 
>> <binary-pkg os='linux' sub-os='fedora' 
>> os-ver='4'>http://mirror.xfce.org/downloads/foo.rpm</binary-pkg> 
>> <binary-pkg os='solaris' 
>> os-ver='9'>http://mirror.xfce.org/downloads/foo.local</binary-pkg>
>> 
> The problem here is that it will require lots of work to get all
> these binary packages up-to-date. In order to reduce this, we can
> perhaps just build some of these depending on their dependencies.
> (In fact I don't really like being distros-based). The installer
> can then fetch the binary package which fits the bests with the
> system he is on.

I don't see this as a problem.  Look at it from an average user's point
of view: all they want is to get the weather plugin installed and
working.  They don't care how, and they may not (probably won't) even
care if it's not the absolute latest whiz-bang version.  As long as it
works, and they didn't have to jump through any hoops to make it work.

> Benedikt speak also about a way to register each goodie in the
> local package management systems. When it can be nice, I hope you
> also tought to the fact that if the user use then his local package
> management system to remove this goodie, the installer must also be
> able to see that this one was removed. (In fact I'm not a fan of
> distro-based packages managment systems, at least for desktops) I
> think the best is to keep a trace of the files who were installed
> so that the installer can remove them later.

Well, for this, Benny was mainly talking about integrating InstallIt
with the package manager.  So, after you compile the weather plugin, it
either creates an RPM (or whatever) and installs it, or mucks with the
package manager in some way to register the installed files as a
package.  You have the same problem here: the user has to have the
proper dev tools and dev packages installed.  The main benefit here is
that the user can uninstall the package later via the normal system
package manager.

>> Jannis Pohlmann wrote:
>>> Each goodie provides a file with compile
>>> options and information about version, name etc.
>>
>> I agree this and also think it must be done on a per goodie basis.

Absolutely.  This is pretty much useless if it's not done on a
per-package basis.

	-brian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFDAP5a6XyW6VEeAnsRAliRAJ0cDXT5tTzpEeDMNAxQCiSzhTaboQCgjU4M
6zHTshUXlFku+bXVmNRT5iA=
=/tAI
-----END PGP SIGNATURE-----