On 1/8/08, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Tue, 8 Jan 2008 18:44:22 -0800 > "Alec Warner" <[EMAIL PROTECTED]> wrote: > > > Uh... So where do the original problems come from? Are you saying > > > that packages mysteriously start breaking on their own because > > > no-one's maintaining them? > > > > Of course they do > > Ah, right. Because of the magical elf that lives in the CVS server > that mysteriously goes around breaking dependencies when no-one's > looking. > > Yes, a magical elf. Much more plausible than the theory that it's > actually developers screwing up by dropping keywords or best keyworded > version on a package's deps.
I was going to go with 'the stable glibc changed' or 'some lib this software depended on was updated to a new version' or any other action that could cause software to not work as intended. I'm not trying to make the argument that developers don't screw up. Certainly mr_bones can attest that they do it on a daily basis. I think the argument here is that developers control ebuilds. If a given ebuild is causing 'trouble' for a maintainer it is within their control to remove the ebuild. Just as if a given package is causing the maintainer grief it can be deleted from the tree, so can keywords for a given arch be removed for a given ebuild (and possibly that ebuild removed because it is known to be old and buggy.) If the arch team wants that ebuild in the tree they should do some work to keep a given package up to date in terms of other arches or we should define some sort of metadata that notifies people that the arch team is the 'maintainer' for a given version of a package. I agree that you should not break the arch's tree by removing a given package (or it's last stable ebuild). -- [email protected] mailing list
