Re: Removing obsolete packages

[David Howland <dhowland%users.sourceforge.net@localhost>]

Thomas Klausner wrote:
> On Sat, Aug 12, 2006 at 08:34:42PM +0200, Krister Walfridsson wrote:
>> pkgsrc-wip contains IMHO far too many obsolete packages which
>> makes it hard to find the useful stuff (and cause extra work when
>> all packages need to be updated because of infrastructure changes).
>>
>> In particular, there were 143 failures in my latest pkgsrc-wip
>> bulk build that failed because the distfiles could not be fetched.
>> I find it unlikely that anyone will miss those packages (since they
>> cannot be used without the distfile anyway) so I'd like to remove
>> them...  There is however no need to hurry, so I propose to wait
>> for three months before removing them, to let people who care about
>> those have plenty of time to find alternative locations for the
>> distfiles.
>>
>> I have attached a list of the failing packages.  I propose to remove
>> the packages that still can not fetch their distfiles at November 15.
> 
> Could we mark the packages in some way so that it is clear that
> this package will be removed, something like the BROKEN_IN
> stuff in pkgsrc?
>  Thomas


I think marking it would be a good idea, and sending an email direct to 
the maintainer.  I had several packages that failed due to missing 
distfiles, and they are not abandoned.  I already had the distfiles on 
my machine, so I didnt know until the bulk build.  I'll be fixing them soon.

By the way, thanks for the bulk build!  I find this very useful,  I wish 
they occurred more often!

On another note, this may be a good time to bring up something I've been 
thinking about regarding WIP.

It seems there are a lot of packages in wip that are broken, abandoned, 
out-dated, or duplicates.  In fact, I'm thinking as many as half of the 
packages are like that.

WIP stands for work-in-progress after all.  What if there was a method 
of tracking every package in wip.  Each package would have a state, off 
the top of my head, I'm thinking READY, INPROGRESS, NEEDSUPDATE, 
ABANDONED, DUPLICATE.  Then, each package maintainer (or anyone else) 
would write justifications for being in a particular state.  This would 
be like an extended TODO file for packages in WIP.  The way I envision 
it is with some kind of automatic checking that would check the states, 
notify the maintainers, find duplicates, etc.  But of course I have no 
time to write such a thing.

So, picture a website with a list of all of the packages.  Click on one 
of mine, cb2bib, and you'd see something like:

INPROGRESS
   - Enable support for using optional features with pdftotext and tetex
   - Verify the portability of patch-ab

(thats from the current TODO file in that package)
Then, after the bulk build a few days ago, it would read:

NEEDSUPDATE
   - Fails bulk build (link)  Cannot find distfiles
   - Enable support for using optional features with pdftotext and tetex
   - Verify the portability of patch-ab

You get the idea.

There would be no more mystery about what is going on with each package, 
  and after a few months, the repository could be cleaned out.

Just throwing it out there.  Let me know what you guys think.

-d

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
pkgsrc-wip-discuss mailing list
pkgsrc-wip-discuss%lists.sourceforge.net@localhost
https://lists.sourceforge.net/lists/listinfo/pkgsrc-wip-discuss