On Fri, 24 Sep 2004 02:06:01 +0200, Rainer Duffner <rainer_at_ultra-secure.de> wrote: > Am Fr, den 24.09.2004 schrieb Jose M Rodriguez um 1:38: >> On Thu, 23 Sep 2004 17:51:17 +0200, Benjamin Lutz <benlutz_at_datacomm.ch> >> wrote: >> >> > Hello, >> > >> >> Our ask is about comments, notes and approvals to: >> >> ... >> >> - patchs against xorg-clients (and sim) to move xinit/xdm config to >> >> /etc/X11 >> > >> > Hm... I really like FreeBSD's way of keeping / as clean as possible, >> only >> > adding 3rd party files to /usr/X11R6 an /usr/local. What about >> > /usr/X11R6/etc? Btw, this is one area where I think it's a bad idea to >> > emulate Linux, most Linux's /etc dirs are a mess. >> > >> >> I must disagree with this. >> >> A port must install from tarball under his ${PREFIX}. >> If it have anything else to do, it must use pkg-install. >> But it may obey config out of ${PREFIX} >> In fact, several ports obey config out of ${PREFIX} via rc-subr. > > > That's true. I'd also like to know why that was implemented this way. > I think that it get you good 'deployment mechanics'. >> The use of ${PREFIX}/etc as the only point of control may get >> you more problems that expected: >> >> - You can't share ${PREFIX} among machines with differents setups. > > Indeed you can't. > But last time I did this (admittedly, this was when 3.x was stable...), > you just had to have different configurations on the server and use > different automounter-configs on the client. That way, the client always > got the right configuration, provided the amd-config was right in the > first place. > If you have a *local* XF86Config, you just shift the problem (can't > share) from the server to the client. It becomes a distribution-problem. > >> - You get a very sparse config system. > > Not really, /etc, /usr/local/etc and /usr/X11R6/etc. > And in several others like /usr/local/share/config, /usr/local/jdk, /usr/local/private ... I'm not sure it is so good or so bad. But I'm sure that Unix trends towards joint machine config under /etc where possible or convenient. And that is not good be so rigid with those things. All this only have pros and cons. > >> + Most difficult to secure. >> + Most difficult to automate. > > > I can't see why. One is more difficult to automate than the other. > There aren't proven rules, only time after and admin console. > > > cheers, > Rainer -- josemi -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/Received on Thu Sep 23 2004 - 22:25:22 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:13 UTC