On Fri, 26 Oct 2007, Dan McGee wrote:

On 10/26/07, Andreas Radke wrote:

...

I will start removing packages now. It seems nobody else has the time or interest to do it. I will use Eric's list in our dev wiki.

step 1: orphaned packages that are no (make)depends for any other pkg. I wonder about Eric's comment "Package | Reason to remove it. No reason implies we keep it"

I think it should be the opposite. If any developer wants to keep it he should adopt it before it will be removed. If we won't do it that way we will stay for months for comments what the reasons are why we want to remove them. The reason is the poor (non existing) maintainership and low usage according the public wiki list.

Don't change the rules on your own just yet- for now, I'm sure there are plenty of removals that can proceed that have been commented on. However, I do agree that the list will probably just sit there if we can't touch a package that hasn't been commented on.

**NOTE to devs- take a quick look at this list and comment on the packages you know can be purged from extra!**

As I said to Andy on jabber, I went through that list last night and will continue tonight. I'll sent the current list of removal canditate with their reason on this ML for discussion/approval. Also I have only checked for make/dependencies for extra packages. They might be depends for unstable, community or optional depends through post-install message. This should be checked before doing the removal. If a package is a depends for a community package, it should remain in extra until its added in community by a dev or TU as we don't want to break depends.

...

Is it ok to rm the whole cvs files including history and the package itself? I see no important reason why we should put the cvs history and pkg somewhere else. If any user or TU wants to pick it up again they would have to do it from scratch again. But we can also hold the cvs entries somewhere for backup for a while. I would need permission on that directory. Your choice.

-1 here. Why on earth would we have to do that? Version control is used for a reason, and rewriting history is rarely a smart thing to do. If empty directories in your checkouts are an issue, try using a .cvsrc file: $ cat .cvsrc cvs -q diff -uN rdiff -u checkout -P update -dP

The removed packages should be put in unsupported; the only exception being packages that are removed because the sources have disappeared. The reason is that a lot of work has been put in these packages. We'll probably remove some packages with non-trivial PKGBUILD with accompaning files such as patches, .install file, scripts, etc. It only makes sense to let the new maintainer benefit from this work. I am ready to do all this and will work intensily on the cleanuip over next week. It's only a question of going through the list to make sure we don't remove a package that should remain in extra. Another point that hasn't been mentionned yet, after the cleanup/adoption, we'll need to do the same with the bug tracker. A lot of packages have changed maintainers so bug reports will need to be reassigned to the new maintainer. Bugs for removed packages will need to be closed with the links posted on the packages page in AUR to let any potential maintainer aware about them. We can worry about that later after the cleanup though. Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.