perfsonar development work

[Gijs Molenaar <>]

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 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.



-- 
Gijs Molenaar
http://gijs.pythonic.nl

Attachment: signature.asc
Description: OpenPGP digital signature