[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
long-broken packages (some are removal candidates)
On Sun, Apr 01, 2012 at 01:21:40PM +0200, Thomas Klausner wrote:
> I remember many of these packages from previous lists of yours. Could
> you please make a list of packages that have been broken for a year
> now, with the aim of removing them if noone speaks up for them
> (promising to fix them)?
I don't have accurate data and I don't think spending time wading
through the pkgsrc-bulk archives is all that worthwhile, as the
exact details aren't that important.
Here's a list of packages that might be considered based on what
appears regularly in failure lists. I've excluded some that break
regularly and get fixed, some that have been worked on but remain
Some of them probably shouldn't be removed; others could be if nobody
This requires running a self-extracting archive in a prehistoric
binary format, I think COMPAT_NOMID. There's no support for this on
amd64. It might work on i386. AIUI there is no more useful way than a
self-extracting archive to get this source, but it might be possible
to switch to a Linux binary instead. Or we could drop it.
The distfile for these has disappeared and redistributing it isn't
allowed. Last I heard someone was trying to track down the author to
This has major C++ issues and AIUI is dead upstream and replaced by
other packages that do work. Should be removed.
Will not build because p5-gdbm is borked on some platforms and/or some
build environments. It got partly, but not fully, fixed a while back.
PR 44985. (p5-gdbm should be fixed, not removed.)
databases/sqlsharpgtk, graphics/f-spot, net/dcsharp
These all suffer the same problem with mono linking:
error CS0006: Metadata file `Mono.Data.dll' could not be found
This has been broken ~forever, so these are possibly candidates for
removal if nobody can be bothered to fix the problem.
This breaks in various ways and has been failing for ages; the
underlying problem is that it builds with scons. I'd say it's a
This is currently marked BROKEN because it conflicts with the base RT
package. It has been this way for a substantial length of time; given
that it's probably easy to fix I suspect nobody cares and therefore it
should be removed.
This has not been buildable in ages, although the way it fails now is
not the same as the way it was failing last fall. There was also, as I
recall, some question as to whether it's even needed. It's not clear
if it should be removed (I'm sure asau@ thinks not) but if it's only
wanted on some platforms it should be masked on others.
I believe the conclusion during the last freeze was that this should
This has been busted ~forever and is probably a removal candidate.
This is way out of date with respect to C++ standards drift and should
almost certainly just be removed.
This got broken a long time back by reckless updating (IIRC) and the
fix wasn't easy or trivial. I forget the details. Things have changed
a bit now, so those issues might be less of a problem, but it still
doesn't build and I expect ~everyone's given up trying. If anyone
wants this they should speak up and preferably take charge of it.
This has been failing on Boost stuff for a long time. If nobody wants
it badly enough to fix it, or update it, maybe it should be removed.
This has not built in years. Someone(TM) needs to figure out what the
upstream story with xemacs is and how to proceed.
The distfiles for these have been missing for a long time. The usual
objects to removing packages for missing distfiles apply, I guess.
This has been failing on Boost stuff for a very long time. I think
it's getting to be time to think about removing it, although there
does appear to be an upstream update available.
This has not been updated in years and also hasn't built in years.
Upstream is active (last release was early March) and I think it would
be good to continue to have this in pkgsrc; as I've said in the past I
think the question is whether the existing package has any value as a
starting point for an update vs. starting over from scratch, and I'm
not sure which way that goes.
This has been failing in the same bizarre way ~forever. I tried fixing
it at one point and more or less failed. Given that gcc3 is very
outdated now, probably it should be abandoned.
The distfile for this hasn't been fetchable for ages. Usual objections
to removing packages with disappeared distfiles apply. I'm not sure if
anyone's checked if there's an update available.
This has been unbuildable for a couple years, ever sinec the last
major version update of ocaml. AIUI, it doesn't require anything but
updating. If no upstream update is available, then it should
definitely be removed.
This is like aqsis in that it needs a complete rework; I don't know if
it's better to keep what's here or nuke it and let someone start over
This has been broken on its x264 codec for ages. It is not clear to me
that this package has much value.
This package is badly messed up; it's not clear how much of this is
upstream lossage and how much is wrong packaging and/or years of
untested changes. It's not clear how (or that) it ever worked. It is
also dead upstream. Should probably be removed.
The upstream distfile is not redistributable and changes fairly
frequently without notice. Therefore, it is ~always broken and will
break again fairly rapidly if someone bothers to fix it. So unless
someone wants to keep it and take on the responsibility of maintaining
it (or wants to try to teach upstream how to release software) I don't
think it's worth the hassle. Should be removed.
Was rolled into base Perl years ago. Should be removed.
This has persistent build problems and hasn't fully built in quite a
while, if ever. It also contains its very own C++ interpreter. (Not
sure to what extent this is the same as lang/cint.) It does appear to
be maintained upstream though. Not clear
Has not built in ages (does not like current or anything like current
ffmpeg) and is an ancient version; there are three newer versions of
vlc in pkgsrc. There does not appear to be anything using it any more,
so it's probably time for it to go.
Has not built in ages, as best as I recall. At the moment the problem
seems to be nothing more serious than broken config file handling. But
if nobody's using it, it seems like it might be a removal candidate.
This hasn't built in a good while. It's not clear there's anything
deeply wrong with it, but it may be a removal candidate on apathy
This shouldn't be removed if possible, but it hasn't built in a long
time ("an AFS sysname is required") and it would be nice to sort that
out properly again.
This also hasn't built in a long time, and hasn't been updated
upstream since 2004. I don't think there's anything badly wrong with
it, but if nobody's using it maybe it should be removed.
This has not built in a long time, if ever, at least on amd64.
Supposedly it builds on i386. Perhaps it should just be marked
Uncompilable (C++ problems) and dead upstream. Unless someone wants to
take charge of this it should probably be removed.
I don't think this has ever worked within the last few years. For a
long time all gnustep stuff was broken; when someone got around to
fixing that, it became possible to try building this, and it didn't
work then and hasn't worked since. Probably someone who understands
objc could fix it. I'm not convinced that there's much point though.
sysutils/ipw-firmware, sysutils/iwi-firmware, sysutils/iwi-firmware3
The distfiles for these have been missing for some time. As these are
things people probably want, Someone(TM) should try to track down what
"Can't locate Config/AutoConf/Linker.pm in @INC". Has been this way
for quite some time. Prior to that I think it didn't build for other
reasons. May be a candidate for removal on apathy grounds.
There's nothing obviously wrong with this other than that the PLIST
doesn't match. However, it's been that way for a couple years.
(People without PKG_DEVELOPER set may be using it, though.) Should
probably be fixed rather than removed.
Like ocamlduce, broke after the last major ocaml update, which was
some time back. However, there's an update available in gnats; I was
intending to apply that after the last freeze but haven't had time.
Typical openssl lossage, but has been broken for a long time. As with
others, this may be a removal candidate if nobody wants it.
This hasn't built in ages. There's some question as to whether
devel/SOPE, which manu@ imported a while back, is a newer version of
the same project. If so, this should be pruned.
This does not work with current X servers. There's a newer
xf86-input-ws on the download page which might. But if nobody's using
it, maybe it's better to drop it.
David A. Holland
Main Index |
Thread Index |