goodies-management

[Jannis Pohlmann]

Brian J. Tarricone schrieb:
> 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.

Yeah, that's absolutely correct. Besides packages which already are
prepared as DEBs, RPMs or whatever we should offer those two different
ways of installing a (source) package: either via our package manager by
just installing (and tracing) from source or by creating a
platform-compliant binary package (DEB, RPM, ...).

Either way we should provide easy-to-do uninstallation for the packages
since the user might be confused if one package behaves different from
another.

> 
> 
>>>>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.

Right. The packages list should just contain the package name, its
download URL, version and perhaps its type (DEB, RPM, source, whatever).
That's still to be discussed in detail.

> 
> 	-brian
> 

Jannis