Old binary packages.

Lamar Owen wrote:

I am looking at the possibility of cleaning up the binary tree on the ftp
site, and was wondering what the group thought about purging old binaries.
What I was thinking would be to remove all but the last minor release of each
major version. Thus, I would remove 7.4, but leave 7.4.1. The space taken
by binaries is significant (about 1GB at this point). Since we are keeping
all source releases (although I would question that, since we use CVS),
keeping all the binaries around is just a space waster, IMHO.

I would keep 7.3.5, 7.4, 7.4.1 (as 7.4 is the current release) and then
do as you suggest
for the older binaries.

J

Comments?

-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL

Lamar Owen <lowen@pari.edu> writes:

I am looking at the possibility of cleaning up the binary tree on the ftp
site, and was wondering what the group thought about purging old binaries.
What I was thinking would be to remove all but the last minor release of each
major version. Thus, I would remove 7.4, but leave 7.4.1.

I concur with Josh Drake's thought --- leave releases that are less
than, perhaps, six months old, even if they have been superseded in
their series. Superseded releases that are older than that could be
dispensed with.

regards, tom lane

Lamar Owen wrote:

I am looking at the possibility of cleaning up the binary tree on the
ftp site, and was wondering what the group thought about purging old
binaries. What I was thinking would be to remove all but the last
minor release of each major version. Thus, I would remove 7.4, but
leave 7.4.1. The space taken by binaries is significant (about 1GB
at this point). Since we are keeping all source releases (although I
would question that, since we use CVS), keeping all the binaries
around is just a space waster, IMHO.

Unless you know that someone is actually running out of space, I think
it would be better to keep past releases around. I've needed them more
often than you would think.

-----Original Message-----
From: Peter Eisentraut [mailto:peter_e@gmx.net]
Sent: 20 January 2004 00:21
To: Lamar Owen; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Old binary packages.

Lamar Owen wrote:

I am looking at the possibility of cleaning up the binary

tree on the

ftp site, and was wondering what the group thought about

purging old

binaries. What I was thinking would be to remove all but the last
minor release of each major version. Thus, I would remove 7.4, but
leave 7.4.1. The space taken by binaries is significant

(about 1GB at

this point). Since we are keeping all source releases (although I
would question that, since we use CVS), keeping all the binaries
around is just a space waster, IMHO.

Unless you know that someone is actually running out of
space, I think it would be better to keep past releases
around. I've needed them more often than you would think.

On that note, new mirror providers often comment on how small our ftp
area is compared to most others. I've *never* heard a complaint about
the size.

Regards, Dave.

On Monday 19 January 2004 19:35, Lamar Owen wrote:

What I was thinking would be to remove all but the last minor release of
each major version. Thus, I would remove 7.4, but leave 7.4.1.

Perhaps check the download figures for each first?

--
Richard Huxton
Archonet Ltd

On Monday 19 January 2004 03:53 pm, Tom Lane wrote:

Lamar Owen <lowen@pari.edu> writes:

I am looking at the possibility of cleaning up the binary tree on the ftp
site, and was wondering what the group thought about purging old
binaries. What I was thinking would be to remove all but the last minor
release of each major version. Thus, I would remove 7.4, but leave
7.4.1.

I concur with Josh Drake's thought --- leave releases that are less
than, perhaps, six months old, even if they have been superseded in
their series. Superseded releases that are older than that could be
dispensed with.

I'm gong to wait a day or so to see what other input comes through, but this
is the way I'm currently leaning. I will make a full mirror of what is there
now on my own box, and then if somebody screams loudly I can restore things.

While disk may be cheap, it ain't so cheap that wasting it is a good thing.
With the source releases still available way back, havng binaries that old,
while useful to some, is not IMO in the best interest of all.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu

Dear Lamar Owen ,

Since we are keeping
all source releases (although I would question that, since we use CVS),
keeping all the binaries around is just a space waster, IMHO.

Comments?

Keeping 7.X and then 7.X.y where y is the last minor version for 7.X is
fine
As you would have noticed from the [general] list that people are still
stuck to 7.2 branch
So IMO keeping 7.2 with as said (7.X.y) is Okay
but please dont take of 7.3 > till 7.4
Because PostgreSQL is the primary and only source for the distribution
and if for any reason some one need old version where will he/she go?

--
Regards,
Vishal Kashyap

~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
I Know you believe my words so logon to Jabber.org
and add vishalkashyap@jabber.org to your roster.
~*~*~*~*~*~*~*~*
I am usually called as Vishal Kashyap
but my Girl friend calls me as Vishal CASH UP.
This is because others know me because of my generosity
and my Girlfriend knows me because of my CASH.
~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*

Lamar Owen wrote:

While disk may be cheap, it ain't so cheap that wasting it is a good
thing. With the source releases still available way back, havng
binaries that old, while useful to some, is not IMO in the best
interest of all.

But where are the spec files and other stuff that belongs into the old
RPMs? Just the source releases are not enough if someone needs to deal
with old systems. And since you mentioned it, creating a source
tarball from CVS does involve human factors and cannot be repeated at
will.

Some people are still using 7.2, for example, and the first thing you
want to do if you go there is upgrading to the latest 7.2 release. By
removing the binaries without any pressure you're just throwing
obstacles in people's ways. I for one will have to make a full mirror
pretty soon because I do need those old files.

On Tuesday 20 January 2004 01:36 pm, Peter Eisentraut wrote:

But where are the spec files and other stuff that belongs into the old
RPMs? Just the source releases are not enough if someone needs to deal
with old systems. And since you mentioned it, creating a source
tarball from CVS does involve human factors and cannot be repeated at
will.

I am willing to make up tarballs of the specs, patches, and scripts that were
used for each source RPM. Or just leave the source RPM ready to rebuild in
place; just getting rid of the precompiled stuff. Looking at the directory
listing that is there right now:
v7.0 v7.1 v7.1.2 v7.2 v7.2.2 v7.2.4 v7.3.1 v7.3.3 v7.4
v7.0.3 v7.1.1 v7.1.3 v7.2.1 v7.2.3 v7.3 v7.3.2 v7.3.4 v7.4.1

(oops, that reminds me that I need to roll 7.3.5 packages....argh)

I would look at removing:
v7.0 v7.1 v7.1.2 v7.2 v7.2.2 v7.3.1 v7.3.3
v7.1.1 v7.2.1 v7.2.3 v7.3 v7.3.2
which would leave:
v7.2.4 v7.4
v7.0.3 v7.1.3 v7.3.4 v7.4.1

And there's nothing there prior to 7.0. I can, if demand arises, resurrect
the 6.5, 6.4, 6.3, and 6.2.1 binaries.

But there are serious bugs in some of those versions; keeping them up really
doesn't serve a purpose: why would we want precompiled binaries for 7.2.2,
for instance?

Some people are still using 7.2, for example, and the first thing you
want to do if you go there is upgrading to the latest 7.2 release. By
removing the binaries without any pressure you're just throwing
obstacles in people's ways. I for one will have to make a full mirror
pretty soon because I do need those old files.

I would leave the last minor of each major in place, just removing the minors
we know to be buggy. So, to use your example, 7.2.4 would be there for the
7.2.x users still among us. And this wouldn't touch the source releases at
all.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu

Keeping 7.X and then 7.X.y where y is the last minor version for 7.X is
fine
As you would have noticed from the [general] list that people are still
stuck to 7.2 branch

We have a large number of people using phpPgAdmin with 7.2.x...

Chris