that's great :)

Thanks for doing that.
That's exactly what I done with XCB ebuilds. Maybe some of you don't
know xcb, it a remplacement for Xlib. Currently it only available on
cvs. I think it couldn't have to be ignore it.

Some ebuilds for :

Website :

Also It's on heavy devlopment, and I'not a dev. So take the choice
you'll find the best :)


On 8/1/05, Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> Hash: SHA1
> (This is an expanded, updated version of a recent blog post, so some of
> you may have already seen parts of it.)
> Background: Upstream is splitting up the monolithic X.Org X11 release
> into a huge number of modular releases, the combination of which will be
> released as X11R7. Simultaneously, a source-identical monolith will be
> released as X11R6.9.
> Gentoo will only add X11R7, the modular release. Roughly 280 packages
> will comprise this release, so this will entail adding a few new
> categories to deal with them.
> Here's the categories I'm looking at using, which is mostly a mirror of
> how upstream breaks it down:
> ~    * x11-apps: The various applications that come along with all X11RX
> releases. 86 ebuilds.
> ~    * x11-proto: The protocol headers. 30 ebuilds.
> ~    * x11-libs: 43 ebuilds.
> ~    * media-fonts: 35 ebuilds.
> ~    * x11-drivers: All the video and input drivers. 68 ebuilds.
> ~    * x11-base: The actual X server, and meta-ebuilds. <10 ebuilds.
> ~    * app-doc: Old-format docs that haven't been broken into individual
> packages yet. Probably just a couple ebuilds.
> ~    * x11-misc: The data module, which contains bitmaps and xkbdata.
> Also the util module, with imake, etc. <10 ebuilds.
> The new categories are x11-apps, x11-proto and x11-drivers. Of these,
> the name for x11-proto (the protocol headers) is debatable. The upstream
> module they're all in is called "proto," and their pkg-config (*.pc)
> files are called fooproto. But I'm also open to names such as
> x11-protocol or x11-headers, so let me know what you think makes the
> most sense, both in understanding the meaning and in combination with
> upstream's naming.
> My plan is to have a series of "submetabuilds" that combine into a
> "supermetabuild," which will be the actual xorg-x11 ebuild. There will
> be one submetabuild for each major component: apps, drivers, libraries,
> etc. This will allow me to split USE flags out a bit (so e.g., x11-fonts
> would have 100dpi, 75dpi, truetype as flags) as well as allow people who
> only want e.g. libraries for a headless server to get them cleanly.
> I intend to begin adding these packages to the tree shortly after the
> first release candidate, which should be happening very soon.
> Repercussions:
> All packages in the tree will need to clearly enunciate exactly which
> parts of X they need as DEPENDs and RDEPENDs, down to the library or
> application level.
> Until such time as that becomes possible for everyone to do, the
> x11-libs metabuild will PROVIDE virtual/x11. But realize that not
> everybody will have or want all the X libraries installed, when they
> only need a few.
> If your package depends on virtual/x11 for any reason besides libraries,
> it will require a dependency update to work with the new packages.
> My preliminary work on the modular ebuilds is at
> -- browse this at your
> leisure. The metabuilds are all in x11-base/. There will be no tarball
> of this overlay available because I'm not interested in dealing with
> other testers before the first release candidate has even come out.
> I eagerly await your questions and concerns.
> Thanks,
> Donnie
> Version: GnuPG v1.4.1 (GNU/Linux)
> WURqd84yUyrb9cJqmiZE6sc=
> =L4yH
> --
> mailing list

-- mailing list

Reply via email to