Re: Python Update Program



Hassan Aurag wrote:

>  Hi,
>
>  Just to be clear, I don't work for Helix or plan to do so. But I have
> your message below to be weird.

That sentance was weird....

>
>
>  No rpm specifics, no apt specifics, no gnome specific, nothing specific.
> Well this is great. You have solved LSB problem. Please forward that
> message to these folks. And while you are at it, I'd like to see
> something for people who don't like your program ;)
>

OK, maybe a little bit of specifics.... ~,^  Basically, the update program can
update ANY list of packages from any server, not just GNOME stuffs.  Later,
like I said, I'll make A GUI version for GNOME (though I'll try an' make it
usable for other archives too).

By non-RPM specific, I meant I don't want to build any kind of RPM code into
the program.  If anything, I'd prefer an option like 'install-program' that
could be set to 'rpm -U' for example, and 'check-package' which could be set
to 'rpm -q'.  I'd like to make this non-built-in so that a simple config
option would allow users of any Linux (or even UNIX) system to upgrade files.

As a related project, a computing club I'm involved in with a local high
school wants to make a Linux distribution, and something I was planning was
making it work with both RPM and apt... so that both types of packages could
be installed, but hack the programs so they shared a common database, so that
for example 'rpm -qa' would list packages that had been installed with apt,
and that upgrading a package that was installed with apt could be done with an
RPM... this would be kinda complicated, but that's the cool part of having
10-20 bright high-school kids with fresh minds: they'll figure it out,
eventually.  ~,^  But this is totally off topic....

Um, anyways, I haven't really gotten any updates on the package type list...
I'm jsut finishing up a few things, and I'll release the next version.  The
only major features that need to be done is the ability to recurse in
directories on the remote site (instead of just using a single directory) and
the options to call an install program.  The only problem there is determing
dependencies, which will be very difficult to do in a package-inependent
manor...

Hmm, now I'm thinking maybe a plugin/module approach would work.  Using the
update program, you could install the rpm-module, which would simply be a
Python script that exported certain functions, that could do etc, and an
apt-module, that exported the same functions but operates on debian stuffs
instead.. OK, I know what I'm gonna work on the rest of the night!  ~,^

Sean Middleditch

>
>  DISCLAIMER: Just poking at you with a rough stick :)
>
> > I don't want RPM specifics... I'd prefer something as package independent
> as
> > possible.  Plus I don't want any dependencies on any programs besides
> those
> > the system will have for sure (Like RedHat/Mandrake/Caldera/SuSE hacing
> RPM,
> > or Debian having apt, etc.).  The update program isn't only for gnome.
> >  Although I may make a specialized version with a GTK/GNOME GUI later on
> > specifically for upgrading GNOME, a bit like the Helix CODE Updater, but
> > much more stable and usable for people who don't like Helix GNOME.
>
> > Sean Middleditch
>
> > >
> > > --
> > > work : ke@suse.de                          |          ------    ,__o
> > >      : http://www.suse.de/~ke/             |         ------   _-\_<,
> > > home : keichwa@gmx.net                     |        ------   (*)/'(*)
> > >
> > > _______________________________________________
> > > gnome-devel-list mailing list
> > > gnome-devel-list@gnome.org
> > > http://mail.gnome.org/mailman/listinfo/gnome-devel-list
>
> > _______________________________________________
> > gnome-devel-list mailing list
> > gnome-devel-list@gnome.org
> > http://mail.gnome.org/mailman/listinfo/gnome-devel-list





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]