Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Development (http://www.linux-archive.org/debian-development/)
-   -   planning to remove xprint, libxprintutil and related packages (http://www.linux-archive.org/debian-development/516810-planning-remove-xprint-libxprintutil-related-packages.html)

Drew Parsons 04-21-2011 12:15 PM

planning to remove xprint, libxprintutil and related packages
 
Xprint has been obsolete for some time now, and it's time to let it go
to rest. It was originally useful as a solution for printing non-latin
webpages from iceweasel 2, but that firefox problem has been fixed since
iceweasel 3 was released using cairo.

Xprint provided a kind a "wysiwig" API by which you could print from an
app using the normal X11 API. Maybe that should be "wypiwys" "what you
program is what you see". Displaying "on paper" instead of "on screen",
as it were. Today that kind of functionality is better programmed
through cairo.

I'm planning to schedule xprint for removal shortly but wanted to give
this notification in case any odd individuals are still finding use for
it. Though they should have already noticed the message in the version
in squeeze that it was obsolete :) Actually I'm expecting more a
response of indifferent cheers than cries of dismay...

The xprint family of packages lined up for removal is:
xprint xprint-common
xprint-utils
libxprintutil1 libxprintutil-dev
libxprintapputil1 libxprintapputil-dev
libxfontp1 libxfontp-dev libxfontp1-dbg

While animosity has been directed towards the xprint package, leaving
the other packages sitting quietly minding their own business, I don't
think it really makes sense to keep shipping the libxprint libraries if
there is no xprint. Please speak up if you think libxprint* or
xprint-utils should stay anyway.

libxp6 and libxp-dev are in a different position. I don't think it
particularly makes sense to keep them either, same as libxprint*, but
they have a bundle of reverse depends:
libxp-dev: lesstif2-dev libcoin60-dev libecore-dev gromacs-dev
libxp6: arb ddd dx fop grace gridengine-qmon lesstif-bin lesstif2 libdx4
libdx4 libecore-x1 libmotif-dev libmotif4 libxbae4 libxp-dev libxp6-dbg
motif-clients mtink twpsk whitedune xastir xtel
So I'll put libxp into the too-hard basket now and won't touch it.

cc: iceweasel maintainers: please drop the iceweasel suggests on xprint
now!

cc: xcb maintainers: should you keep libxcb-xprint0 ? Do we need to talk
about this? libxcb-xprint0 has no relation (in a packaging sense) to
xprint.

Cheers,
Drew

Julien Danjou 04-21-2011 02:22 PM

planning to remove xprint, libxprintutil and related packages
 
On Thu, Apr 21 2011, Drew Parsons wrote:

> cc: xcb maintainers: should you keep libxcb-xprint0 ? Do we need to talk
> about this? libxcb-xprint0 has no relation (in a packaging sense) to
> xprint.

I see no harm providing it. It exists, so we can just let it be. Nothing
depends on it I guess, and nothing should ever depends on it, but I
don't see any good reason not to build it either.

If you really want to hide that Xprint ever existed, maybe that'd be a
reason to stop building that package, otherwise, I don't see really any.
:)

--
Julien Danjou
❱ http://julien.danjou.info

Jamey Sharp 04-21-2011 02:55 PM

planning to remove xprint, libxprintutil and related packages
 
On Thu, Apr 21, 2011 at 04:22:17PM +0200, Julien Danjou wrote:
> On Thu, Apr 21 2011, Drew Parsons wrote:
> > cc: xcb maintainers: should you keep libxcb-xprint0 ? Do we need to talk
> > about this? libxcb-xprint0 has no relation (in a packaging sense) to
> > xprint.
>
> I see no harm providing it. It exists, so we can just let it be. Nothing
> depends on it I guess, and nothing should ever depends on it, but I
> don't see any good reason not to build it either.
>
> If you really want to hide that Xprint ever existed, maybe that'd be a
> reason to stop building that package, otherwise, I don't see really any.
> :)

Speaking as both a Debian user and an XCB developer:

- I think we'll leave xprint.xml in xcb-proto forever, because it's
protocol documentation that may be useful to somebody.

- In libxcb master, I'd be happy to change configure.ac to default to
not building xprint. I'd personally continue building it because I
build all known extensions, just to check for build regressions, but
there's no reason everybody else needs to.

- For Debian, while I can't argue with your point, Julien, that "I don't
see any good reason not to build it," I also don't see any good reason
*to* build it, and I have a lot of sympathy with wanting to "hide that
Xprint ever existed." :-)

Jamey

Julien Danjou 04-21-2011 03:18 PM

planning to remove xprint, libxprintutil and related packages
 
On Thu, Apr 21 2011, Jamey Sharp wrote:

> - In libxcb master, I'd be happy to change configure.ac to default to
> not building xprint. I'd personally continue building it because I
> build all known extensions, just to check for build regressions, but
> there's no reason everybody else needs to.
>
> - For Debian, while I can't argue with your point, Julien, that "I don't
> see any good reason not to build it," I also don't see any good reason
> *to* build it, and I have a lot of sympathy with wanting to "hide that
> Xprint ever existed." :-)

If the decision to disable its building by default in XCB is taken, I
think we should follow XCB decision in the Debian packaging and disable
(or "not enable") its building.

But for the XCB-side decision, I really don't have enough hindsight to
have a decent opinion, so I'll leave that up to you. :)

--
Julien Danjou
❱ http://julien.danjou.info

Drew Parsons 05-15-2011 11:20 AM

planning to remove xprint, libxprintutil and related packages
 
On Thu, 2011-04-21 at 17:18 +0200, Julien Danjou wrote:
> On Thu, Apr 21 2011, Jamey Sharp wrote:
>
> > - In libxcb master, I'd be happy to change configure.ac to default to
> > not building xprint. I'd personally continue building it because I
> > build all known extensions, just to check for build regressions, but
> > there's no reason everybody else needs to.
> >
> > - For Debian, while I can't argue with your point, Julien, that "I don't
> > see any good reason not to build it," I also don't see any good reason
> > *to* build it, and I have a lot of sympathy with wanting to "hide that
> > Xprint ever existed." :-)
>
> If the decision to disable its building by default in XCB is taken, I
> think we should follow XCB decision in the Debian packaging and disable
> (or "not enable") its building.
>
> But for the XCB-side decision, I really don't have enough hindsight to
> have a decent opinion, so I'll leave that up to you. :)
>


Following up the Xprint removal, I've submitted the request for my
xprint packages to be removed.

I'm happy with whatever decision you think is best for XCB, whether it's
best to keep providing libxcb-xprint0 for compatibility with your
upstream.


> If you really want to hide that Xprint ever existed, maybe that'd be a
> reason to stop building that package, otherwise, I don't see really
> any.

No, no, it's not like that :) I'm quite proud of the little service
Xprint provided in its time, I don't want to hide it! In fact I made
sure a final version was sleeping soundly in snapshot.debian.org for
anyone in the future who might want to call it up.

So leave libxcb-xprint0 in if you prefer! I just wanted to make sure
you knew that the xprint server is going to be gone.

Regards,
Drew




--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1305458432.8473.12.camel@pug">http://lists.debian.org/1305458432.8473.12.camel@pug


All times are GMT. The time now is 06:45 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.