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

Bug#362750: xserver-xorg: 'xserver' provides dropped without explanation?



On Sun, Apr 16, 2006 at 09:52:52PM +0300, Daniel Stone wrote:
> On Sat, Apr 15, 2006 at 02:09:57PM -0700, Steve Langasek wrote:
> > On Sat, Apr 15, 2006 at 11:33:08AM +0100, Daniel Stone wrote:
> > > On Sat, Apr 15, 2006 at 03:05:04AM -0700, Steve Langasek wrote:
> > > > The current xserver-xorg package no longer Provides: the virtual 'xserver'
> > > > package, which all xserver packages have done since time immemorial (or at
> > > > least since sarge).  As there is no mention of this in the xserver-xorg
> > > > changelog, I imagine this was removed in error.

> > > I removed it.

> > Are you going to deign to tell me why?

> If you are relying on a working X environment, you just need to depend
> on the set of X libraries you use.  If you're relying on a specific
> server, you need to launch that server.

> No server that I know of will reliably start and work when invoked
> without any DDX-specific parameters.  Not Xorg, not Xgl, not any of the
> KDrive-class servers.

> Okay, Xephyr and Xnest will, but they are not what you want when you
> depend on the 'xserver' package.

> Same reason I made xresprobe invoke /usr/bin/Xorg directly, instead of
> calling through the /etc/X11/X symlink and just hoping that it worked.

> Although, upon writing this mail, I'd imagine that ?dm Depends:
> xserver-xorg | xserver, is an entirely valid use case, as they require
> an X server to be startable, use no DDX-specific parameters, and do not
> take responsibility for X server configuration.  If that's what you had
> in mind, then yeah, I'm wrong.

Right; the packages in unstable that depend on "xserver" today are ldm,
lessdisks-xterminal, sdm-terminal.  But only as a last alternative, so maybe
this isn't really an issue anyway.

In stable, login.app is added to this list without any alternatives, which
was how I noticed the dropped Provides.  And login.app's dep is obviously a
bug.  So yeah, given how few packages care about this virtual package, seems
fine to drop it and close this bug.

> Either way, adding it back won't draw any complaints from me.  Merely
> noting that it was removed deliberately, not accidentally.

<nod> understood.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature


Reply to: