Darren J Moffat wrote:
> x11/clients
>
> This split up seems quite excessive to me, I can't imagine wanting to
> install at that level of granularity. On the other hand as long as I
> can do 'pkg install x11/clients' and get them all no big deal I guess.
Having heard many complaints over the years about our X packages being
too huge for people trying to minimize, I probably went too far the
other direction, which is why I asked for feedback before going too far
down this route. Trying to find more logical & useful groupings will
take a bit of thought though.
> x11/header
>
> Why not developer/x11
Because the existing package name used since 133 was x11/header - that
package of all headers is split into the protocol headers in this package
and the individual library headers in each of their packages.
> x11/keyboard
>
> Doesn't seem to me like splitting this down to the command level is
> necessary.
x11/keyboard/accessx is already it's own package, and since it's the old
Motif-based gui makes sense to keep split out to avoid bringing Motif
dependencies into the main package.
x11/keyboard/xkbcomp is used by the X servers (for now) to compile the
XKB data files into the XKM binary format the servers read (there's a
long term plan to move this into a library instead of having Xorg
fork & exec a program everytime you startup or change layouts) - having
it separate makes sense as the xserver packages will depend on it, but
not the other keyboard utilities.
setxkbmap I have no good reason for keeping split out from xkbutils.
xmodmap is the pre-XKB utility so doesn't logically fit into "xkbutils",
but could be grouped in if a better name was thought of.
> x11/library
>
> That one looks reasonable, but other than the Xtsol case why would I
> want to pick and choose these at this low a level given the dependencies
> between them ?
Mostly the dependencies will be a shallow tree - most of the extension
libraries depend on libX11 & libXext, but there are few interdependencies
between them.
Splitting them to the individual library level allows those building other
software that uses autoconf style auto-detection to explictly choose which
packages are installed in their build environment and not unexpectedly pick
up new dependencies on newly added libraries. (Those who do want to have
new libraries automatically picked up as they're added can just install them
all.)
> x11/session/xcompmgr
>
> Shouldn't this be x11/window-manager/xcompmgr ?
>
> I know it doesn't actually replace the window manager but complements
> it, but its own name suggests it is a window-manager.
Compositing manager, but yes, that might also make sense under
x11/window-manager.
--
-Alan Coopersmith- [email protected]
Oracle Solaris Platform Engineering: X Window System
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
