any point in removing dead patch directories from CT?

[Robert P. J. Day]

On Thu, 20 Oct 2005, Allan Clark wrote:

> Robert P. J. Day wrote:
> >   just for aesthetics, is there any value in getting rid of some of
> > the patches subdirectories that seem redundant?  for example, stuff
> > like glibc-20040822 and others like that?
> CT == crosstool?

yup.

> If so, they should be migrated to a "the unpopular archive" so that
> they might be out of the big, standard archive, but if someone needs
> them, they're around *somewhere*... one thing about crosstool is
> that it can sometimes build the toolchain for working on older,
> forgotten devices.

i understand that, but i was also pondering the value in marking
earlier releases as flat out deprecated or unsupported or something
like that so that users are discouraged or even *prevented* from using
them anymore.

that wouldn't apply to actual versioned releases no matter how far
back they go, but it might be useful for things like nightly or weekly
snapshots or dated CVS pulls for which newer releases or pulls really
should supersede older ones and make those older ones redundant, at
least to some extent.

as a stunningly trivial example, consider the sanitized kernel
headers.  version 2.6.11.2 needs a single patch, while the fixed
2.6.12.0 version needs no patches at all.  what about just stating,
"use the newer, correct version to make everyone's life simpler"?

one way to support this would be to mark some versions of software as
"dead" by having a patches/ subdirectory that contains a single empty
file with a name like "DONTUSE" or "OBSOLETE" or something.  or maybe
even renaming the patches directory to something like
linux-libc-headers-2.6.11.2-DEAD so it's even more obvious.

just thinking out loud while the caffeine takes its sweet time kicking
in.

rday

p.s.  the above occurred to me when i compared the software versions
supported in the patches/ directory with the results of the CT build
matrix, and noticed that most of those transient versions are not
represented in the matrix, which makes perfect sense.

it struck me that, if a particular version of software is not listed
in the build matrix, it's probably, in some way, redundant and can
eventually be dropped from support.

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com