cvsup-mirror rewrite

João Carlos Mendes Luís jonny at jonny.eng.br
Wed Dec 15 10:53:12 PST 2004


Jeremie Le Hen wrote:
> On Thu, Dec 09, 2004 at 12:27:38PM -0200, João Carlos Mendes Luís wrote:
>>[...]
> 
> Well, I won't be deeply convinced that using ${PREFIX}/${PORTNAME} as
> installation target it the cleanest thing to do while the core team
> won't direct us to do so.  In fact, I think your arguments are not so
> bad and I'm going to adopt your point of view for a first try in the
> code rewrite (anyway changing installation location is not so hard),
> even if it's totally breaking hier(7) IMHO.
> 
> But for now, I'm quite harassed that both hierarchies are used in the
> same time ; I think this is going to be a mess if port maintainers
> are able either to spread the port files accross the standard hierarchy
> (hier(7)) or to simply put them all in ${PREFIX}/${PORTNAME} depending
> on their own policy without further control.

Again, my own view on the subject:

- I do agree that most packages should follow hier(7), or we may get 
into a mess like the one created by Solaris /opt scheme.  This is the 
most important point in my view, and the probably he main reason for 
hier(7) existence and for core team resistence.

- I do not have a hard opinion on where should be the default ${PREFIX}: 
should it be /usr/local, as in FreeBSD, or simply /usr as in linux? 
I've been using Unix since AT&T Unix Version 7 on PDP11/70, and 
/usr/local has grown as a standard for *local* files, not system files. 
  But are ports/packages local or system files?  In this sense, is 
hier(7) already broken?

- I do not want to change every user PATH ech time a new package is 
installed, so this is a great reason to follow hier(7).

- On the other hand, the packages I like to keep out of hier(7) are 
those which are not for direct end user (or administrator user) to use, 
or which are reasonably complex to mix with other system files.  If I 
had to genericly classify which ones to put, I would say that the 
following classes are subject to this separation:
   - Packages that may have simultaneous versions installed, and the 
user should have the choice to select: java, mozilla, perl, gcc, etc.
   - Packages that are for sole use by daemons and that may have large 
data or logs files and hierachies: apache, squid, postgres, etc.
   - Packages that are for sole use by daemons and although data and log 
files are not really big, they fit better together, as a small group of 
related files: nut, cvsup-mirror, arpwatch, etc.

   In any class some common files (like wrappers) could be in the 
default hier(7) distribution.  Note that some of the packages referred 
above already break hier(7) in the default instalation.  Some others do 
not, but I do break it in some of my personal installations.


     Note: This discussion is probably already very far from the 
original.  A good point about it is that the hier(7) documentation could 
be updated from info gathered here to allow such breakages, explain the 
reasons and guide future porting.


More information about the freebsd-hubs mailing list