goodies-management

[Jannis Pohlmann]

Wit Wilinski schrieb:
> On Mon, 15 Aug 2005 22:18:03 +0200
> Nicolas Masse <masse_nicolas at yahoo.fr> wrote:
> 
> 
>>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. 
>>
>>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.
>>
> 
> 
> What if we just had binary plugins instead of packages? The
> goodie-manager would check if compilation is possible - if not, it'd
> try to find the best binary plugin for the user's system? Using local
> package management system would make the case a lot more complicated
> (and a bit system-dependant). I think that listing several goodies in
> the package database is a bit overhead. It could be misleading too -
> the user could be confused, where to delete the plugin: in the goodie
> manager or in the package manager.
> 

The packages we talk of are not only goodies and they're not only .so
files. We talk of a more generic solution. Listing some packages in one
file (and spread the whole system over about two or three directories)
cannot be called "overhead".

> just my $0.02
> BTW. if the goodies manager will be written in python/pygtk, i'd like
> to help, also ;)

I was talking with Johannes and we both agreed with Benedikt, so it will
be most probably written in Python using PyGTK and some Glade for the GUI.

Personally, I like the current Xfce developer situation in which teams
of one or two persons work on one project together while the others
sometimes look at the code and provide patches. But of course you can
help in any way.
I already prepared a preliminary "roadmap" which I discussed with
Johannes and which I'd like to offer to the list later this day. In this
roadmap the first steps are brainstorming and discussion, not coding.
The coding itself won't be too much work so I guess we won't need that
much help there. Anyway, what we'll absolutely need is ideas and feedback.

> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> http://foo-projects.org/mailman/listinfo/xfce4-dev