perfsonar development work

[Roman Lapacz <>]

Gijs Molenaar wrote:
> Jochen Reinwand wrote:
>   
> > On Mittwoch, 24. September 2008, Gijs Molenaar wrote:
> >   
> >     
> > > Jochen Reinwand wrote:
> > >     
> > >       
> > > > Hi Gijs,
> > > >
> > > > sorry to say that, but you are really wrong.
> > > > What you describe is only applicable for /usr/local and even there it is
> > > > not really strictly forbidden to install software the way perfsonar is
> > > > doing it.
> > > >
> > > > LSB is not really saying much about /opt and filesystem hierarchy at all.
> > > > See one interesting part here:
> > > >       
> > > >         
> > > Implicitly it does.
> > >
> > > http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-ge
> > > neric/execenvfhs.html
> > >     
> > >       
> > Indeed! Must have overlooked that...
> >
> >   
> >     
> > > > Looks like the way perfSONAR installs is basically OK, but we can do some
> > > > tuning here...
> > > > One big problem is, that the Java part of perfSONAR is a web service and
> > > > not really a normal application. LSB and FHS cannot easily be applied
> > > > here.
> > > >
> > > > The rules you are referring to are most likely Debian specific and AFAIK
> > > > only of interest if you want to get your package included in the Debian
> > > > distribution. Because then you create a "system packages" and these
> > > > packages are indeed not allowed to put something in /opt. Just as LSB and
> > > > FHS imply.
> > > >       
> > > >         
> > > Well, not really system packages, just correct packages. The idea of
> > > packaging is that your software is integrated into your distribution and
> > > the management of the files is done by the package manager.
> > >
> > > http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1
> > >
> > > Darn, I can't find anything about /opt, only about /usr/local and this
> > > isn't allowed.
> > >
> > > Ok I misquoted the LSB, but I remember that somewhere is defined that
> > > using /opt is a bad idea, can't find where. In pactice it isn't used in
> > > packages, so I don't see why perfSONAR should use it. People wouldn't
> > > expect stuff to be installed in /usr/local or /opt when a package is used.
> > >     
> > >       
> > I think this problem is also related to the "new" way of package management. A 
> > few years ago I normally expected software that is not directly included in 
> > the distribution to install in /opt or /usr/local. But today third party 
> > repositories are quite common. Packages from the repositories you normally 
> > expect to install just like system packages.
> > So we have:
> > 1. Third party software from a "common" package repository. Most likely 
> > managed by someone else, not the third party. => system packages
> > 2. Software directly from a third party vendor. Very often not as a normal 
> > package and most likely not via a repository. => /opt
> >   
> >     
>
>   
> > perfSONAR is at the moment the special case between 1. and 2.: From a third 
> > party vendor, but as a proper system repository. Not that easy to decide, I 
> > think...
> >   
> >     
> Well, I would say we are most likely as number 1 :).
>
> So if there is doubt, why not just not use /opt? Is there any special reason 
> to use /opt in the packages, even if this violates the debian policy, or to 
> some extend, the FHS policy?
>
> Using /usr/lib/perfsonar/package seems reasonable to me. The only problem is that config files arn't in /etc and state files aren't in /usr/var, but this can be 

in such case I would keep symlinks proposed in U.S

Roman

> solved in the future (future release, not now) by moving stuff to the correct 
> places and creating symlinks. This is how Mailman, squirrelmail and packages 
> like that are RPM'd and DEB'd. Or we can decide not to do this in the future, 
> but at least then there is the option.
>
>
>
>