cvs commit: ports CHANGES UPDATING ports/Mk bsd.port.mk ports/accessibility/linux-atk Makefile pkg-plist ports/archivers/stuffit Makefile ports/astro/linux-setiathome Makefile ports/audio/baudline Makefile ports/audio/linux-arts ...

[Alexander Leidinger]

On Sat, 25 Jun 2005 21:42:57 +0200
Michael Nottebrock <lofi at freebsd.org> wrote:

> On Saturday, 25. June 2005 21:06, Alexander Leidinger wrote:
> > On Sat, 25 Jun 2005 20:24:27 +0200
> >
> > Michael Nottebrock <lofi at freebsd.org> wrote:
> > > > So whoever wants to talk the last word on this issue should update the
> > > > documentation.
> > >
> > > No need, it's been documented in hier(7) for years. You're obviously not
> > > the first person to have missed that though.
> >
> > Quoting hier(7):
> > ---snip---
> >        X11R6/    X11R6 distribution executables, libraries, etc
> >                  (optional).
> >                  bin/      X11R6 binaries (servers, utilities, local
> >                            packages/ports).
> >                            ^^^^^^^^^^^^^^                      ^^^^^
> >                  etc/      X11R6 configuration files and scripts.
> >                  include/  X11R6 include files.
> >                  lib/      X11R6 libraries.
> >                  man/      X11R6 manual pages.
> >                  share/    architecture-independent files.
> > ---snip---
> >
> > I understand the marked parts as if we complain with hier(7) if ports
> > which use X11 are installed there.
> 
> I really have no idea how you're arriving at that conclusion. It doesn't say 
> "ports which use X11". 

The X11R6 distribution contains servers, utilities and more (libs/data
files/...). Specifying them and then adding "local packages/ports"
suggest to me, that not only binaries which come with the X11R6
distribution are allowed to reside here.

I interpret "X11R6 binaries" as "binaries which make use of the X11R6
protocol" and not as "binaries which come with the X11R6 distribution
only".

> I mean, really, if anybody would stop for a minute and think about this - what 
> sense does putting everything that somehow links to or displays stuff via X11 
> into a common prefix make???

Let's say you have a common subset of applications which doesn't need
X11 (compile clusters, servers, compute systems, shell boxes, whatever)
and install into LOCALBASE. You want to have them on every machine. And
you have a subset of systems which are supposed to make use of X11
software (e.g. desktops).

You can now export the pieces which make use of X11R6 to only those
systems which can make use of it (think about a policy which reserves
some machines to a specific use and you don't want to let users misuse
their access to those systems). Only giving access to the software
which is actually needed is common behavior in a lot of places. Yes, we
have ACLs now, but it's less work to just export the necessary bits
than to write complex ACL rules (and AFAIK a computer is supposed to
simplify productive work and not supposed to generate more work as
needed to support the productive work).

> X11R6 historically lives in X11R6 so it's easy to keep *separated* from 
> everything else and its own huge hierarchy doesn't mess up whatever UNIX 
> variant's filesystem layout the user installs it on. If we keep cluttering up 
> its hierarchy with stuff that isn't part of X11R6, there's no reason left to 
> keep that hierarchy at all - we could just as well put X11R6 into /usr/local.

So you're saying that just because you can't imagine how the current
behavior can be useful to people, it isn't useful?

Just make it clear: 
 - I don't want to make a bikeshed here.
 - The current de-facto standard is to install software which uses X11
   into X11BASE (with some exceptions).
 - I think this behavior should stay, but I will not participate in any
   bikeshed which discusses this issue (I can live with a change).
 - The current documentation is ambiguous regarding this issue, else we
   wouldn't have such many ports which install in X11BASE.
 - As long as we don't document in a prominent and public place what
   the desired way "from now on" is (this includes making the files we
   have talked about unambiguous), I will follow our de-facto standard.
 - As soon as a new way of doing it is published, I will follow it.

Bye,
Alexander.

-- 
            Secret hacker rule #11: hackers read manuals.

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7