Re: new X11R6 packages
Ian Murdock writes ("new X11R6 packages"):
> * The "xbaseR6" and "xr5shlib" dummy packages have been removed now
> that dpkg supports virtual packages. This requires, of course, the
> use of dpkg 0.93.50 or later. (dpkg will be BETA later this week, and
> Ian J. appears to have no objections to including it with the official
> 0.93R6, so I think it is reasonable to remove the dummy packages).
That's right. In order to safely use the new dpkg you need at least
0.93.62, and in order to upgrade safely from earlier versions you need
at least 0.93.63 unless your bash is sufficiently old not to be
broken.
There haven't been any killer bugs since then,
> * Rather than depending on "xbaseR5 | xr5shlib" or "xbaseR6 | xr6shlib",
> as older Debian packages have done when they required a certain version
> of the X Window System, packages should depend on "X11R5", "X11R6", etc.
> as appropriate:
> PACKAGE: some_package_needing_X11R6
> DEPENDS: X11R6
> The older scheme will still be supported for a few more months.
You need to distinguish between
(a) programs which need the X shared libraries because they are X
clients, but can run perfectly happily without X on a character
cell display (eg Emacs).
(b) programs which are X clients only, and therefore need the X
shared libraries. They should also Recommend an X server,
as the user will probably want to be able to display their
windows locally.
(c) programs which are part of the X serving side of things, for
example the fontserver (if it were a separate package). These
probably Depend on an X server.
So, we need at least three virtual package names:
- one for packages to Depend on which need an X library, but not
necessarily a functional one (ie, it is allowed to return `failed'
to all the X calls).
- one for packages to Depend on which need a functional X library.
- one for packages to Recommend if they want an X server. The
name of a preferred X server package (probably xsvga) should also
be published, so that the packages can ensure that the default is
right.
> * The XpmR6, Xpm_compR6 and Xpm_develR6 packages have been merged into
> a single package called "xpm". "xpm" will provide "xpmR6", but
> all new packages needing XPM should depend on "xpm", not "xpmR6".
> (They should also depend on "X11R6"--see above.)
Do we not need to make a distinction between packages that are linked
against the xpm shared library and ones that need its development
version ? IMO we should do this even if we're currently shipping them
both in one package.
James A. Robinson writes ("Re: new X11R6 packages "):
> > * The XpmR6, Xpm_compR6 and Xpm_develR6 packages have been merged into
> > a single package called "xpm". "xpm" will provide "xpmR6", but
> > all new packages needing XPM should depend on "xpm", not "xpmR6".
> > (They should also depend on "X11R6"--see above.)
>
> I thought depending on xpm would automagically resolve to depending on
> a virtual package of X.
Yes, I should imagine so, but one should list all of one's own
dependencies directly.
> > * A week or so ago, someone made the suggestion that we separate the
> > X11R6 shared libraries from the xbase package. This would allow us,
> > perhaps, to remove the -nox and -x versions of packages and replace
> > them with a single version of the package which is linked to these
> > shared libraries (and which depends on the package containing them).
>
> It would be very nice to get rid of the x, no-x duplication.
Indeed. I think a 500K package is a reasonable price to pay for the
reduced confusion.
In due course we can produce a stub X library package which simply
says `no' to every call.
Ian.
Reply to: