Re: [system-tools] package-maintaining

[Karel Demeyer <kmdemeye vub ac be>]

Hi,

Op ma, 17-01-2005 te 23:09 +0100, schreef Carlos Garnacho:
> Hi Karel!,
> 
> On Thu, 2005-01-13 at 21:12 +0100, Karel Demeyer wrote:
> > Hi,
> > 
> > I'm new to this list, and I didn't read all the archives yet :| I just
> > joined to give a feature request.  I'm not a coder, I don't know if it's
> > possible, but I'm a gnome-user and I think following would be super;
> > 
> > Could it be possible to have a "Software installer" in the G-s-t ? It
> > could be some frontend-backend thing.  So, you have one frontend GUI
> > that looks the same for all distro's/package-managers and a backend per
> > package-manager.  Plus, for all distros there should be a GUI to "./
> > configure && make && make install" that keeps the source for de-
> > installation.  the frontend should be a bit like Synaptic does for
> > Debian.  I don't know really, but I think it should be possible to have
> > the same GUI for other distro's/pkg-managers.  no ?  It should be noce
> > to have an overview of all installed packages, click to install or
> > remove packages etc ... the same for each gnome-user, whatever distro
> > they use. :)  
> > 
> > again, I'm not a coder, don't know about it.  maybe some others have
> > proposed this before and I'm nr. X in a row... 
> 
> This would be a really nice feature which is needed in other parts of
> GST (i.e: installing NTP stuff instead of giving a silly warning), but
> there are some issues that will make this a bit hard.
> 
> The main problem I see is the diversity of package models (source
> packages vs precompiled packages, hability to fetch them from internet,
> etc...), this by itself is not the big problem, but to give users a
> proper experience, the backend should notify to the frontend the stage
> of the installation (downloading/compiling/installing/error/couldn't
> connect/conflicting files/...), and bidirectional comunication is still
> missing in GST...
I see :)
> 
> The next development will be probably aimed to fix this, so it would be
> a nice feature to think about, but at the moment the best you could find
> is RedCarpet from Ximian/Novell, which already manages a couple of
> packaging systems
> 
> 	Regards, and sorry for the delay answering
It's great to have a positive reply, take your time :).
> > 
> > I'd like to hear some respons though :)
> > 
> > friendly greeting,
> > 
> > Karel 'scapor' Demeyer.
> > 
> > BTW: this backend-frontend-thing would make it possible to also create a
> > QT/CLI interface and use the same on all distributions while they still
> > use _their_ packaging-system
There are so much answers to the problem of the big number of package
management systems, most jkust want to create a unified system.  I think
it's kind of wrong to do that as it 'blocks' competition between
ditributions, as we'll never see "the ultimate package management".
Everything can be made better, always.  I mean, we better have a unified
frontend for all systems then the same package management for all
distros as it's one of the things a distro makes special.  Sometimes I
think there should be unified packages, to make new apps spread
quicklier, and therefor .package etc is a Good Thing, but once g-s-t has
such a system there should "only" be made a backend for it.
> 
> Yep, that's the great advantage of the backend/frontend arquitecture,
> althought it isn't being used a lot (still :)
I've seen it in some programs before and that made me believe it has a
great 'power'.  

Sorry if I sound stupid - as I don't code but try to "tellhow I see it"
etc :| I just want to help 'the community' with my thoughts.  I think it
will be a big work but one that will be appreciated (I hope) if it
should get done.  

Thanks anyway for your reply!

friendly greeting,

Karel Demeyer.
http://gnometux.blogspot.com -- Gnome : T.U.X. - The Users eXperience
> 
> > 
> > _______________________________________________
> > system-tools-list mailing list
> > system-tools-list gnome org
> > http://mail.gnome.org/mailman/listinfo/system-tools-list
>