On Sat, 11 Dec 1999, Louis Glassy wrote:
> Just thinking out loud- would it make sense to 
> have a process in place to remove or reclassify broken
> packages from the collection?  I.e.  to "deprecate" packages
> or move them into a "no longer works & no one cares" category?

or to say "this package is fine, but don't build it in bulk builds"
this could be of interrest to prevent conflicting pkgs or pkgs foo and
foo-current.


> With all the emphasis on growth, it seems to me
> that we can accumulate packages that with gradual
> changes to the package collection, will no longer
> compile, nor find enough takers to get them working
> again.  Would it make sense to have a now-non-working
> package put in some kind of "deprecated" category, 
> so that people can browse through the package collection
> and see that a package was compiled and run back in 
> NetBSD-1.3/amana-microwave, but has never been
> gotten to run since then?  

Well, quite now the list of broken packages it quite small. we still have
some fallout from the defuzzing and some other minor problems, see
ftp://smaug.fh-regensburg.de/pub/NetBSD/pkgstat/19991211.1534/broken.html.

In general I'd suggest to mark individual packages that way, and don't
move them around in pkgsrc - ways too much CVS overhead etc.
And for some of the cases you mention, hooks already exist: setting
variables like BROKEN will not attemp to build a package, indicating that
it's broken, and why.


> Yes, that's additional work (having a "non-working"
> package list?), but the nice thing about it, is that
> just about no other free Unix-like OS's (except maybe
> Debian Linux) will actually _tell_ you that a package
> really doesn't work anymore.  Instead, you have to find out
> the hard way.  So if NetBSD could do this, this is 
> something we could point to & say "This is an example
> of our quality control in action." 

I'd prefer the quality control to fix the pkg in that case. :-)


> Now, you might think, well, if a package is broken, then
> The Right Thing to do is fix it.  ---Sure, if there is someone around
> with know-how and time and interest to fix it.  It would still
> be good (I think) to keep code available, even when there is no
> current maintainer for it, in case a new maintainer comes along.
> Maybe I need XFooBlozWoggit badly enough, that I'll fix it to 
> run with the current set of libraries.

.if ${MAINTAINER} = "packages@netbsd.org"
BROKEN=		unmaintained
.endif
:-)


> Anyway, just thinking out loud.  What do you all think?  Would it 
> be practical to distinguish working packages from "orphaned" ones?

In theory, the idea is nice. in practice, it needs work to mark packages
as broken. 


 - Hubert

-- 
NetBSD - Better for your uptime than Viagra