On Sun, Oct 26, 2003 at 11:46:39PM +0100, Frank Lichtenheld wrote: > On Mon, Oct 27, 2003 at 06:46:41AM +1000, Andrew Pollock wrote: > > As I mentioned recently[1], I'm working my way through the list of > > packages at http://qa.debian.org/orphaned.html and uploading them with the > > Maintainer field set to the QA group. As Matthew Palmer suggested[2], I'm > > also attempting to fix "quick win" bugs against the packages. > > Please consider my dxpc and xmake packages which are also in this list > [1] and for which I prepared QA uploads. I'll do that when I get to them (I'm working top to bottom). > > I've gotten up to waba, which has unsatisfiable build dependencies. For > > packages such as these, should I file a bug to have them removed from the > > archive? > > Depends. I would go after some criteria: > 1) Look for a new upstream version which perhaps has updated > build-depends. If it is easy to package (as it was for the two > mentioned above) do it. I'm hesitant to package up a new upstream version of something that I have no knowledge of (and probably no interest in, or I'd have adopted it). I may end up making matters worse for the QA group overall, which is the last thing that I want to do. > 2) Is the package in contrib or nonfree? Policy allows unsatisfiable > (Build-)Depends in such cases. A package can even be in contrib > due to exactly this. waba is in contrib. So it's allowed to have unsatisfiable build dependencies. I still can't produce a new .deb to upload, so the package and I are a bit screwed then. > 3) Apply the normal criteria for removal: number of RC and other bugs, > time of orphaning, importance of the package, etc. > > If you still want to remove the package, write a mail to debian-qa > and propose it together with mentioning your reasons... Ok. > But this are just my opinions... > > > What about unbuildable packages? I think it was snes9express that I was > > unable to rebuild successfully. > > I looked into this package yesterday. There is a new upstream version > available[2] which (according to the changelog) compiles with g++ >> 3 > and with gtk2. But the word "beta" is far to often mentioned in the > release notes, so I wouldn't bother to package this for the QA Group, > this needs a real maintainer. Pretty much the same comments to your point one above apply here. I'm not interested in actively maintaining any of the orphaned packages on this list, I'm just trying to help out by fixing up the Maintainer field (and close any trivial bugs). I would feel obligated to start looking after packages I made wholesale changes to. I'd consider a new upstream version a reasonably big change. regards Andrew
Attachment:
signature.asc
Description: Digital signature