[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Removal of grace, pygrace and expeyes



On Sun, 23 Mar 2014 13:08:14 +0100
Michael Banck <mbanck@debian.org> wrote:

> On Sun, Mar 23, 2014 at 10:03:53AM +0000, Neil Williams wrote:
> > On Sat, 22 Mar 2014 20:38:49 -0700
> > Nicholas Breen <nbreen@debian.org> wrote:
> > 
> > > On Sat, Mar 22, 2014 at 04:10:39PM +0000, Neil Williams wrote:
> > > > I'm seeking the removal of pygrace and expeyes so that grace
> > > > can be removed. CC'ing the relevant maintainers (and filing
> > > > important bugs for each package). I expect the removal to start
> > > > in two weeks unless I hear back about a viable solution.
> > > 
> > > If just getting standalone t1lib out of the archive is the goal, I
> > > don't mind incorporating all of the existing t1lib patches into
> > > the embedded copy. 
> > 
> > No. How does that solve the problem of t1lib being abandoned
> > upstream and already superseded by freetype?
> 
> Why is it a problem in the first place? Software is being rewritten
> and superseded constantly, this doesn't mean other software using
> those old libraries are immediately to be sent to the bin.

It's not immediate. t1lib has had no upstream changes in Debian since
2008!

grace itself has not had upstream changes introduced into Debian since
the same time.

Abandoned software doesn't need to bit rot forever in Debian. If there
is reason to keep it, there is reason for someone to maintain it.
Whilst it remains orphaned, it will be considered unmaintained,
abandoned and suitable for removal.
 
> I think this is the grace's maintainer's call.  But then maybe I am
> missing part of the conversatio and your motivation to have grace
> removed.
 
Personally, I don't think it is good to have an embedded copy of a
removed package inside a package which remains in the archive. What
would be needed is an assurance from the grace maintainer and those who
are keen to retain grace in Debian, that the internal t1lib code would
be maintained inside grace to a better standard than it has so far been
maintained outside grace.

That may be simpler to do if the grace maintainer & interested parties
adopt t1lib (upstream and in Debian). At that point, the problem with
t1lib become manageable again. That would close #637488 and #638760 at
the same time.

> > > As grace is almost exclusively used to plot
> > > locally-supplied numeric data, and is not in any way practical to
> > > use in a network setting, it has minimal security risk vs. some
> > > other former users of t1lib like php5.
> > 
> > The security issues were only one part of this - t1lib has been
> > abandoned and superseded. It is unsupportable, as are packages which
> > rely on it.
> 
> It is being supported by grace upstream as part of the embedded
> library, as written elsewhere on this thread.
> 
> For some values of supported, but I don't see the point in removing
> grace completely.  If you want to get rid of the the t1lib package -
> fine, but I think using the embedded copy is an acceptable solution
> for grace.

This would need to be declared clearly in the grace package
description and maintained as part of grace. It's not the ideal
solution.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: signature.asc
Description: PGP signature


Reply to: