Some cases like the kernel package has a distribution version at the end. The Fedora Legacy package naming will be treated accordingly.
kernel-2.4.20-27.8 kernel-2.4.20-27.9 kernel-2.4.20-28.8.legacy kernel-2.4.20-28.9.legacy
What do you mean "some" cases? Anything that needs to be backported should have a distro tag, which means that the .legacy part is unnecessary. I think you address that to some degree when you speak of packages in the "updates" channel not being updated, only patched. There's already a long history attached with the various distro versions, it's now our job to continue that sordid trail of backporting/patching. In my mind, that's simply justification for s/legacy/rh$VERSION/ and continuing the portage trail.
That all being said, I do agree that in *some* cases, we can upgrade to the latest release version without causing any trouble (fileutils, etc).
I believe we can sanely and easily choose naming on a case-by-case basis. We only need to follow precedent. This is not a problem.
We disagree about having ".legacy" at the end. I personally don't see a problem in having a longer filename since it *should* be handled automatically by tools. I believe we should have it for two reasons:
1) Clear separation between the official RH/FC updates and Legacy updates. 2) Repository tags are encouraged for all non-FC and non-FE repositories.
I suppose we could have a shorter abbreviation of legacy, but I can't think of anything that looks good.
I suppose we could also drop it entirely, but I would encourage not dropping it for the above reasons.
Warren
