Lalo Martins wrote:

On Fri, Sep 17, 2004 at 01:09:47PM -0400, Fred L. Drake, Jr. wrote:

...

I'm still planning to make ZIP archives available. If anyone would like to argue that I should drop that as well, feel free. ;-)

1. the main archive software packages for all OSes support tar.bz2 in their current releases. (This includes WinZip, WinRAR and whatnot.)

2. if you can't be bothered to know what is a tar.bz2 and how to open it, you won't be getting the ZIP, but rather the EXE installer.

.zip is the only one of these 3 formats that allows you to decompress a few files without expanding the entire archive. This feature is useful to me at least (and makes up for the larger size). -- -- Scott David Daniels Scott.Daniels@Acm.Org

Charles Cazabon wrote:

Scott David Daniels wrote:

...

.zip is the only one of these 3 formats that allows you to decompress a few files without expanding the entire archive. This feature is useful to me at least (and makes up for the larger size).

tar supports that as well, and with better compression when paired with bzip2. Hint: tar xzf archive [file] [...]

Right, but the only way it can extract the last file ofthetar archive is to expand the entire arcive (in order to determine the bytes at the end of the archive). .zip looks in the directory for the file, reads the bytes representing the compressed file (and only that file), and uses them to expand the file to its original version.

Charles

-- -- Scott David Daniels Scott.Daniels@Acm.Org

Nick Bastin wrote:

If we're only talking binary releases, then I don't really care, but please don't make this change for the source releases. There are several platforms on which Python is supported which do not support bzip2 out of the box (Solaris, as a prime example). It adds just that much more heartache to get python installed on such a system.

agreed. it may come as a surprise to some people, but Linux is not the only Unix system out there. Python works extremely well on non-Linux systems too... </F>

Martin v. Löwis wrote:

...

agreed. it may come as a surprise to some people, but Linux is not the only Unix system out there. Python works extremely well on non-Linux systems too...

But then, a Unix system does not have gzip, either.

Of the build systems I checked, all had gunzip, most had unzip, but only the Linux systems had bunzip2. The bzip2 homepage contains 1.0.2 binaries for exactly three plat- forms, compared to over 20 systems for gzip and 30 systems for unzip. I suppose older bzip2 versions (0.9.5) are compatible, but someone should verify that they work before you pull the gzip archives.

Maybe IP isn't available, either, so we should ship QIC tapes.

That's a really helpful comment. </F>

Martin v. Löwis wrote:

Fredrik Lundh wrote:

...

Of the build systems I checked, all had gunzip, most had unzip, but only the Linux systems had bunzip2.

Sure, there are systems that don't have bunzip2 installed. However, what is the problem of installing it? All you need is a C compiler, and I'm sure you have one - how else are you going to install Python?

Yes, those with older, bzip2less systems can probably figure out how to get it and build it, but why force them when it's practically no work keeping it? It's one (sic) extra command for the release manager and ~9M extra disk space per release on www.python.org. And besides that... only GNU tar supports the j flag. <wink> Erik

Erik Heneryd wrote:

Yes, those with older, bzip2less systems can probably figure out how to get it and build it, but why force them when it's practically no work keeping it? It's one (sic) extra command for the release manager and ~9M extra disk space per release on www.python.org.

Fred wouldn't have asked if it was no effort in keeping it. There is certainly more than one command to it - you have to md5sum the file, and copy the md5sum into the release notes. You have to upload the file from your workstation to python.org. I don't know how you do that, but I need to use my DSL link for uploading the MSI files; it takes roughly 30min to upload. Fortunately, I have a DSL flatrate. Regards, Martin

Martin v. Löwis wrote:

Fred wouldn't have asked if it was no effort in keeping it. There is certainly more than one command to it - you have to md5sum the file, and copy the md5sum into the release notes. You have to upload the file from your workstation to python.org. I don't know how you do that, but I need to use my DSL link for uploading the MSI files; it takes roughly 30min to upload. Fortunately, I have a DSL flatrate.

Again, we're only talking about the documentation tarballs. I'm still going to be making both tar.gz and tar.bz2 format source releases - yes, it's a bit more work (gotta gpg sign both, upload both) but I'm completely unconvinced that forcing people to install bzip2 everywhere is a useful approach. Anthony -- Anthony Baxter It's never too late to have a happy childhood.

Brett C. wrote:

But either way I completely sympathize with the release managers and I am all for making people's lives easier at release time.

Yep. I suppose that's what this is all about. Should we add 5 minutes of work for: 1) the release manager 2) the n (small integer) people with bzip2less systems Think 1) is the way to go, at least for finals. Oh, whatever, I don't even really care. I'll shut up now. Erik

On Sep 18, 2004, at 4:57 PM, Oleg Broytmann wrote:

On Sat, Sep 18, 2004 at 10:46:10PM +0200, Erik Heneryd wrote:

...

Yep. I suppose that's what this is all about. Should we add 5 minutes of work for:

1) the release manager

Add 5 minutes for EVERY release.

...

2) the n (small integer) people with bzip2less systems

Add 5 minutes to install bzip2 ONCE and forever.

Sure, on every machine that you need to install python on (and it isn't 5 minutes either - most solaris machines aren't that fast). That's assuming that it's acceptable to your corporation to just be adding software to your unix machines that hasn't gone through a qualification process. -- Nick

"When in doubt, don't pass." If there was all around agreement to drop gzip, I'd say go for it. But since there isn't, let's keep supporting it and test the waters again in a year or two. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

Martin v. Löwis wrote:

Within the last few days (since the logs rotated on Sep 13), there have been 1095 accesses to Python-2.3.4.tar.bz2, and 5168 to Python-2.3.4.tgz.

so given the "we'll save 5 minutes for each release, and users stuck with gzip only loses 5 minutes each" rationale, I assume this means that some- one's planning to make 314400 Python releases over the next year? </F>

On Sat, 2004-09-18 at 15:57, Brett C. wrote:

My personal take on all of this is that we make the release manager's job as simple as possible.

Although if someone from the community wanted to volunteer to build tgz files, that might go a long way toward keeping this option available. Disk space on python.org isn't (or shouldn't be) an issue. -Barry

Brett C wrote:

My personal take on all of this is that we make the release manager's job as simple as possible.

first the "no abbreviations in the standard library" and now "who cares about users; releases are for the release manager". have you even seen a Python user in real life? </F>

Anthony Baxter wrote:

Last I looked, tar.bz2 was less than 1/4 of tar.gz in terms of number of downloads (see http://www.python.org/wwwstats/usage_200409.html) That's hardly a case for switching.

Although that may partly result from http://www.python.org/download/ referring to the .tgz only. Regards, Martin

[Responding to an absolutely enormous deluge of emails on python-dev...] On Sunday 19 September 2004 10:06 pm, Anthony Baxter wrote:

I have no intention of dropping tar.gz source releases. I think Fred was talking about the documentation tarballs. Even then, I think there's some advantages to keeping both, and I don't really see the advantage to dropping the tar.gz format. But hey, that's up to Fred - he's the one who makes the doc releases.

Dang, it doesn't pay to be away from email for three days, does it? Yes, I was only talking about documentation releases. It never occurred to me anyone would think I was talking about Python source releases. Maybe I shouldn't have added python-dev to the recipients list for my original email, but too often objections get heard quite late if I don't include python-dev. For the documentation, there's a much longer history of providing the bz2 versions of the archives. There are also many more archives we can drop per release. While in theory disk space isn't supposed to be an issue, it seems to be something our sysadmin group is dealing with on a regular basis (mostly cleaning up old webserver logs). So while the space itself may not be an issue, it certainly generates tedious work for volunteers. My motivation in dropping the bz2 archives is two-fold: 1. Reduce disk space consumed per release, mostly to ease the burden on the sysadmin group. 2. Reduce the number of files posted for the documentation per release, so that choices for end-users are easier to pick through. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>

I'm not sure how easy or difficult it would be---but it would be very convenient for me if the documentation was also downloadable in windows help (CHM) format. Currently CHM files are only available in windows installers, but I use them on Linux (easier to search, etc). -param On Tue, 21 Sep 2004 10:36:15 -0400, Fred L. Drake, Jr. wrote:

[Responding to an absolutely enormous deluge of emails on python-dev...]

On Sunday 19 September 2004 10:06 pm, Anthony Baxter wrote:

...

I have no intention of dropping tar.gz source releases. I think Fred was talking about the documentation tarballs. Even then, I think there's some advantages to keeping both, and I don't really see the advantage to dropping the tar.gz format. But hey, that's up to Fred - he's the one who makes the doc releases.

Dang, it doesn't pay to be away from email for three days, does it?

Yes, I was only talking about documentation releases. It never occurred to me anyone would think I was talking about Python source releases. Maybe I shouldn't have added python-dev to the recipients list for my original email, but too often objections get heard quite late if I don't include python-dev.

For the documentation, there's a much longer history of providing the bz2 versions of the archives. There are also many more archives we can drop per release.

While in theory disk space isn't supposed to be an issue, it seems to be something our sysadmin group is dealing with on a regular basis (mostly cleaning up old webserver logs). So while the space itself may not be an issue, it certainly generates tedious work for volunteers.

My motivation in dropping the bz2 archives is two-fold:

1. Reduce disk space consumed per release, mostly to ease the burden on the sysadmin group.

2. Reduce the number of files posted for the documentation per release, so that choices for end-users are easier to pick through.

-Fred

-- Fred L. Drake, Jr. <fdrake at acm.org>

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/psoberoi%40gmail.com

Fred wrote:

You do? What software supports them? It would be cool to have a decent single-file documentation browser on Linux.

http://xchm.sourceforge.net/ </F>

Paramjit Oberoi wrote:

I'm not sure how easy or difficult it would be---but it would be very convenient for me if the documentation was also downloadable in windows help (CHM) format. Currently CHM files are only available in windows installers, but I use them on Linux (easier to search, etc).

I could do this along with the Windows installer releases. However, I don't think I can do this whenever Fred makes a snapshot release; I also doubt that Fred can easily do this on his own, since the documentation is build on Unix, and the CHM file on Windows. Regards, Martin

Fred Drake wrote:

While in theory disk space isn't supposed to be an issue, it seems to be something our sysadmin group is dealing with on a regular basis (mostly cleaning up old webserver logs). So while the space itself may not be an issue, it certainly generates tedious work for volunteers.

I thought everyone knew that logs always fill up until the disk is almost full, no matter how much disk you have. </F>

*blush* I read the post wrong, please disregard my comment.