Florin Boariu florin at bnv-bamberg.de
Tue Sep 12 07:20:07 PDT 2000


Nevertheless, such a program might be all right. It needn't make _all_ the
suggested things, a simle notice like "hey, there's a new gnuplot out
there" and optionally a download might be even enough. The naming schemes
of (L)GPLed software are fairly consistent, and where they aren't
consistent, they are consequent (i.e. if a program chosses to name itself
v.v.v-package.tar.gz, it will mostly do it all the time).

All you need to do is set up a huge data base like this:

package name	|	url-base		|	naming scheme
GNUplot		| ftp.gnu.org/pub/gnuplot	| \name-\maj.\min.\rev.tgz

and let the program check the url base dir and store the results. You can
view the results once a day and let download the new packages you-re
interested in. Then you can still decide whether you'd like to install it
or not. Of course, you can plug in some version-filters, i.e. accept only
\min version numbers that can be divided by two (for some packages this is
the "stable"-stamp).

All this show can even be done with some shell scripts, your local mail
delivery system and one or two cron jobs. Oh, and some ftp/http program
that can be run noninteractively.

We could use a shared data base. There might even be a good idea to talk
to the people at Freshmeat and use their database... although I think that
would lead a little too far, with 20.000 entries in your local database.


On Tue, 12 Sep 2000, Torsten Vollmann wrote:

> > It would be a *very* useful tool though, if you are able to write such a thing...
> >
> > Maybe such a took would also be useful to the ALFS project, so it could automatically download updated version so the packages, if a newer version is available.
> Well - lets think about it for a moment:
> 1.: Would it be a good idea to integrate new source-versions to the alfs project without further checking? If I have got the message in another posting right Gerard
> is checking every new version bevor letting it slip into LFS...
> 2.: What would this little proggy have to do/know?
> - the base-address of the source-files: ftp.xxx.yyy/pub/source-name/
> - the way the versions are nubered: source-x.y.z.tar.gz
> - wether the version-number is also inside the tarfile: /usr/src/source/ vs. /usr/src/source-x.y.z/
> - it would also be helpfull to download version-histories / changelogs to see what's new
> - then it has to tell the install-programm (ALFS or whatever) that there a new source-file and what it is named
> - and the installer has to know if it is enough to simply compile and install the new sources or if other parts of LFS have to be recompiled, too.
> It sounds like a lot of work - and I have to admit that my time-scedule is to tight at this moment (I already spent to much time with LFS and to less with my
> robotics-studies...) and I've planned to concentrate my LFS-work on learning more about the single packages - but maybe the future will give solutions ;-)
> But we should follow this path, I think...

[...] try this new version instead, which many people believe to
      be the perfect compromise between new and old bugs. :)

	-- announce of ircII 2.9 "roof"

More information about the lfs-dev mailing list