Re: Some little proposals...

["Germano Rizzo" <manomano ciaoweb it>]

Hi! :))

| >     First, why not to use the bzip2 to compress the packages? It
compress
| > far better than gzip, even 700k less in some packages, and it's a
standard
| > just like gzip, nowadays... changing the "Source" field of the specfile
|
| I can't answer this. Does bzip2 work on all the platforms GNOME gets
| built on? If so, this is surely a reasonable idea.

    I think yes. It surely works on unixes (even Solaris, I've tried myself)
and windows, both 9x and NT/2000... I don't mean changing all the packages
to bz2; if disk space isn't an issue, the ideal (and what nearly everyone
actually do, look at the kernel sources) is to ship gzip and bzip
tarballs together...

| Tell me about it. I used to download the diffs, patch, and regenerate
| an rpm. But so -many- of them wouldn't patch. And I am not particularly
| good with patch. Either it works, or I get an error I am not capable
| of dealing with. It was faster in the end to grab the entire new package
| than to get all the patches and attempt to apply them. I did try to tell
| packagers when diffs were broken, but if I couldn't tell them -how-, this
| didn't help much :)
    Yep... you're right. In my experience, diff-ing the packages just with
"diff -Nur" does a good job, when there aren't binaries involved (but the
changes to the binary files should be quite rare in a stable source package)
and the directory tree don't change much (and this should be rare, too)...
But it's a matter of minutes for the packager to make the diff and test
it... and give an 'ideal situation' in which to apply it (e.g. "make
distdir" and apply the patch on the generated directory, then cd to that,
"./configure && make dist" and use the created tarball as the new
archive)...

| I agree totally. For those with little bandwidth, the pace is just too
| much to keep with the latest updates continually. And then you are told
| "this is fixed in latest version" :)
    Yeah... don't think that people with low bandwidth are ignorable... at
least here in Italy, a connection from home is tipically a dialup one, with
an analog modem... I have an university account, but I just can't download
all the stuff there and then bring it home (floppies? =:-O )... If you
download a new version of, say, Evolution, it may require also new versions
of libraries, and so on... so, if you want to try the changes in the new
version... IMHO, this means less bug reporting, too: who cares if there is
gnome 1.4-beta1 out? if I do know that next beta will be other 40 Mb to
download, I just wait for that!

| My solution was to stick with fairly stable stuff,
    Right... anyway, if I'd like to contribute as a bug reporter... :(

| or to upgrade only the minimum stuff. I don't personally use
| gnome-pim, or gnumeric,
    That's right.

| I used to create a script of
|
| ncftpget -F ftp://ftp.mirror.ac.uk/path/to/gnome-update-1.tar.gz
| ncftpget -F ftp://ftp.mirror.ac.uk/path/to/gnome-update-2.tar.gz
| ncftpget -F ftp://ftp.mirror.ac.uk/path/to/gnome-update-3.tar.gz
| ncftpget -F ftp://ftp.mirror.ac.uk/path/to/gnome-update-4.tar.gz
|
| And then use "at -f grablist 4am" to kick it off. By that time (GMT),
| UK users were in bed, and US users were going to bed, and whilst the
| script was going (and it took five hours to download October GNOME)
| the US people went to sleep too :)
    Yes. But 5 hours of connections means money, too, not only time
wasted... :-/

    Well, thank you very much for the answer. I really hope someone will
keep these little advices... it's matter of minutes, after all, to generate
such packages...
    Take care,
        Mano :)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
GnomerMind - an intriguing puzzle
             game for your GNOME!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://gnomermind.sourceforge.net
mano78 users sourceforge net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~