Re: [gentoo-dev] modular X - 7.0 RC1

[Dan Armak <danarmak@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1967 bytes --]

On Thursday 20 October 2005 17:23, Mike Williams wrote:
> On Thursday 20 October 2005 14:26, Dan Armak wrote:
> > To keep the current behaviour, the kde metaebuild (and gnome and the
> > other WMs) would have to depend on xorg-x11, which strictly speaking is
> > unnecessary. Opinions? How can we educate the users to manually 'emerge
> > xorg-x11'? Personally I'm in favor of updating the docs, making a big
> > announcement on all channels, and preparing a nice bug to close
> > duplicates against.
> >
> > We'll also need to educate them about xorg-x11 not installing fonts any
> > longer. The way I understood your metabuilds.txt, 'emerge xorg-x11 kde'
> > would result in an unusable system without any fonts at all...
>
> As a fairly average joe user when it comes to all things X, I feel it would
> be best to keep the current X USE flag behaviour, i.e. a full working
> Xserver. The same goes for xorg-x11, or virtual/x11.
That's not the meaning of the flag. Its meaning is 'enable optional X11 
support'. Usually (almost always) this means client X support.

For apps that really have optional support for the xorg-x11 server, a new USE 
flag might be introduced.

> KDE needs some X libs, so obviously must always depend on them, but having
> the X USE set should call in a complete working server.
>
> For packages that can work with, or without X, and should give the option
> to have a full server, or not, perhaps a new USE flag is needed? Xlibs?
No. That would change the meaning of the X USE flag. We could add a new USE 
flag, but we shouldn't rename existing ones.

In any case, the decision of optional clientside X support (the X USE flag 
today) should be completely separate from the decision of installing a local 
X server.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]