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