perfsonar development work

[Roman Lapacz <>]

Gijs Molenaar wrote:
> Hello people,
>
> I'm trying to get less involved in packaging, but I have to say that I
> disagree with the desision taken in US. It is a small detail, but I just
> want to get this right.
>
> I understand that the reason to install the services in /opt/perfsonar
> is because developers want to have all services (perl/java) in one
> place. The choice of /opt is, in my opinion, bad. iT should  be
> /usr/lib/perfsonar, /var/lib/perfsonar or both, depending how strict you
> want to follow the LSB. I agree that maybe it is not a good idea to
> install all service stuff in /var/lib/tomcat5(.5)/webapps, but using
> /opt is a step back in bringing the quality of the packages up.
>   

I think Gijs's comment is very important and reasonable. In my opinion 
we can accept the proposal to move all stuff to /var/lib/perfsonar 
directory.
It's not a big change but as Gijs said does not violate packaging standards.

Please service developers and release team, send your comments. We need 
the final agreement very soon.

Thanks Gijs for your input!

Roman

> The choice for /opt is bad because:
>  * /opt isn't for package content. opt (and /usr/local) is for manually
> installed software by the administrator for the system.
> * Strict debian package (using deblint) building even doesn't work if
> you put stuff in /opt (or /usr/local).
> * There are standards for these kinds of things (LSB). The whole world
> tries to standarize, this is actually a good thing.
> * For example I use /opt for big packages that I install manually. I
> have a backup script that copies /etc /var /usr/local and /opt, because
> with this data I can restore the system to the state it was in case of a
> crash. I don't want content in /opt.
> * It just looks unprofessional and ugly. When I would encounter a
> package in the wild which installs stuff in my /opt, I would think it is
> a bad package and bad software and I wouldn't like to install it.
> * There is actually no need to use /opt, except that developers and
> users are used to have their stuff in /opt. Let's get this bad habbit
> corrected right now.
>
> I'm making a big issue about this, because you don't want to change the
> paths (or at least as possible) to the configuration files of the
> packages, because otherwise adminstrators need to manually copy their
> configuration files to the correct place. In the case of flowsa-ma it
> can be quite a lot of work to recreate the config file.
>
> Note that there are more LSB violations in the current package schema,
> for example all config files should be in /etc.
>
> Thats all, I hope it is useful.
>
> Roman Lapacz wrote:
>   
> > Hi,
> >
> > It was agreed in Ann Arbor to change a bit the directory structure of
> > installed java pS service (release 3.1). I've made few changes in my
> > packaging files (for rpm and deb) to reflect that.
> >
> > We decided to have service files under
> > /opt/perfsonar/services/<service name>
> > and few additional links:
> >
> >    /var/lib/tomcat5.5/webapps/<service name> ->
> > /opt/perfsonar/services/<service name>
> >    /etc/<service name> -> /opt/perfsonar/services/<service
> > name>/WEB-INF/classes/perfsonar/conf
> >    /var/log/<service name> -> /var/log/tomcat5.5
> >    /usr/share/doc/<service name> -> /opt/perfsonar/services/<service
> > name>/WEB-INF/doc
> >
> >
> > You can take a look at my files to see the changes:
> >  
> > https://svn.perfsonar.net/svn/perfsonar/trunk/geant2-java-rrd-ma/packaging/
> >
> >  
> > https://svn.perfsonar.net/svn/perfsonar/trunk/geant2-java-sql-ma/packaging/
> >
> >
> > Roman
> >     
>
>
>