Re: Removal of grace, pygrace and expeyes
Hi,
This is my summary, see below for specific replies to specific points:
1. Grace is not unmaintained, it is maintained in Debian by Nicholas
Breen. It also is not abandoned upstream, its latest stable release
being from late 2012.
2. As t1lib is superseded and unmaintained, it should be removed from
Debian as a library package.
3. As grace is a useful application, it should remain in Debian. To
this end, with respect to point #2 above, it could start to use the
internal copy of t1lib instead of the external package.
4. As soon as grace is switched to the internal copy, t1lib becomes a
convenience library of grace, similar to thousands of other convenience
libraries in Debian package. In particular, security concerns should be
less pronounced, as grace does not (TTBOMK) run as root, nor does it
listen on the network. Basically, the security concerns should be
similar to any other piece of C/C++ code in any other graphical
application.
5. Nobody gets to tell the grace maintainer at which level the grace
package should be maintained, but everybody is welcome to file bugs and
patches for specific issues.
On Sun, Mar 23, 2014 at 01:17:55PM +0000, Neil Williams wrote:
> 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.
For some values of 2008 being 2012:
|grace (1:5.1.23-1) unstable; urgency=low
|
| * New upstream release. (Closes: #689532)
|
| -- Nicholas Breen <nbreen@debian.org> Wed, 31 Oct 2012 17:09:21 -0700
> 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.
Which package are you talking about here? Grace is maintained by
Nicholas Breen, according to the PTS.
> > 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.
Again, that is not your call to make, but the maintainer's. He is
apparently willing to maintain the grace package, with or without an
internal copy of t1lib.
> 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.
If they want to do this, fine, but it is certainly not necessary for
them. As t1lib is superseded, I think it makes more sense to keep its
code around just for grace inside the grace source package. This will
also discourage other developers from using the t1lib library in their
projects.
> > > > 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.
Internal implementation details like this should not be part of the
description, it could be added to README.Debian and/or README.Source,
though.
> It's not the ideal solution.
Sure, but it's certainly better than removing grace.
Michael
Reply to: