Обсуждение: Old binary packages.
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. Comments? -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
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