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