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

X support, and other alternate configurations



  5.8 Programs for the X Window System 

  Programs that may be configured with support for the X Window System
  must be configured to do so and must declare any package dependencies
  necessary to satisfy their runtime requirements when using the X
  Window System, unless the package in question is of standard or higher
  priority, in which case X-specific binaries may be split into a
  separate package, or alternative versions of the package with X
  support may be provided.

Does this mean that packages can't provide versions of their binaries
without X support? Or does it just mean that those binaries have to go
into a package with other binaries configured for X support?

I'm hacking around with a gnutalk package at the moment; it's already
been ITPed by someone else, so this is just experimentation, not
something I'll be uploading. Anyway, it has ncurses, emacs, lesstif,
GTK+, and GNOME front ends. I imagine some people will want the GNOME
front end; personally, I'd prefer to stick with the ncurses one. My
reading of the above paragraph from policy, though, assuming that
gnutalk-ncurses wouldn't be a standard priority package, is that one of
the following (IMHO undesirable) alternatives must be followed:

  * No X-less binary may be provided.
  * An X-less binary may be provided, but it must go into a package with
    one of the X-dependent front ends. Thus, either an arbitrary
    X-dependent front end must be picked to accompany it (which would be
    odd, I think), or else all the front ends must go into the one
    package (including emacs, which is a pretty vast wodge of
    dependencies for a humble talk client).

Is the intent really to forbid multiple front ends to programs like
gnutalk from being split into separate packages? If so, why, and
shouldn't this prohibition be phrased explicitly in terms of avoiding
too many binary package splits in general rather than an arbitrary
X/non-X distinction? Personally, I'd prefer it if it were allowed,
within reason, to provide versions of packages configured with options
that are equally desirable (to different people) but conflicting.

-- 
Colin Watson                                     [cjw44@flatline.org.uk]



Reply to: