Hi Drew,

A bit of followup to my bug report.

1) You'll need to either epoch xprt or have the xprt package use a
different version number from the rest of your source package[1], since
0.1.0.alpha1-8 is less than 4.3.0.dfsg.1-10.  (It's also less than
4.1.0-16[blah], the woody versions of xprt.)

2) There are alternatives to making xprt a dummy package.  You could
coalesce xprt-common and xprt-xprintorg into xprt if you wanted to, making
xprt-{common,xprintorg} dummy packages instead of xprt if you chose.  Since
those never existed in a stable release, you could probably get away with
retiring those dummy packages before sarge releases, too.

Daniel Stone has just emailed debian-x asserting that "the head of Xprint
development is now X.Org", which is not a statement that is challenged in
any way by my move to drop xprt from the XFree86 packages, but that's
Daniel for you.

In any case, if xprt-xprintorg is now a misleading or confusing package
now, that might provide an additional reason to move the Xprt server binary
into a non-dummy xprt package.

Anyway, how you resolve this report is really up to you.  My main concern
is that the right thing happen for upgraders from woody.  Please feel free
to carry out further discussion on debian-x or ask me for advice if you'd
like any.

xprt is yours now -- may you wear its crown more steadily than I have! :)

[1] I don't actually know how to do this, as I've never had to, but
packages like gcc-defaults do it.  Unfortunately, that's a lousy example,
as I've tried to comprehend that thing's debian/rules before, and it's
quite a challenge.

-- 
G. Branden Robinson                |     Eternal vigilance is the price of
Debian GNU/Linux                   |     liberty.
[EMAIL PROTECTED]                 |     -- Wendell Phillips
http://people.debian.org/~branden/ |

Attachment: signature.asc
Description: Digital signature

Reply via email to