svn commit: r216483 - head

[Alexander Best]

On Fri Dec 17 10, Alexander Leidinger wrote:
> On Thu, 16 Dec 2010 14:22:30 +0000 (UTC) "Bjoern A. Zeeb"
> <bz at FreeBSD.org> wrote:
> 
> [descsription of the original ordering]
> > I think grouping by date and then by file/lib/dir is actually better
> > as it'll keep things logically together rather than possibly splitting
> > it over 3 sections?
> 
> As the person who did the initial ordering: whatever makes sense. Way
> back when I did it, the original ordering made some things more easy.
> Now that the lists grown very big, everyone is welcome to change it to
> something which makes sense today.
> 
> BTW: Should or should we not remove old entries which are way beyond
> what we support, e.g. files from 2nd previous branches? The idea behind
> is, that this prevents to have an abnormal big list of old stuff, and
> that an update from e.g. 6 to 8 is not supported, so people need to go
> from 6 to 7, can delete old stuff, update to 8 and delete again old
> stuff. I am aware that people would have to rebuild all ports on 7 and
> on 8 again, if they want to update libs. I am not sure if this matters.
> If it matters, what about removing stuff which is from a 3rd previous
> branch, e.g. if we delete on 8 it will remove outdated files from 7 and
> 6, but not from 5?

i've seen systems running 7 stable e.g. where sysadmins have never executed
target delete-old and old files from the 2.x and 3.x days are still floating
around.
removing these ancient files from the delete-old target would mean that on such
systems getting rid of such legacy files becomes close to impossible.

personally i don't see a reason to get rid of those ancient entries.

egrep -v '^#' ObsoleteFiles.inc|wc reports:

    4972    5164  222607

which isn't really that much.

just my 0.02$.

cheers.
alex

ps: another possibility would be to have a target delete-old for old files from
the last two releases and a new one called delete-ancient which will delete all
the old stuff from way back.

> 
> Bye,
> Alexander.

-- 
a13x