Skip to Content.
Sympa Menu

perfsonar-dev - Re: java services after installation

Subject: perfsonar development work

List archive

Re: java services after installation


Chronological Thread 
  • From: Gijs Molenaar <>
  • To: Roman Lapacz <>
  • Cc: Verena Venus <>, Cándido Rodríguez Montes <>, Maciej Glowiak <>, Stijn Melis <>, Michael Bischoff <>, "" <>,
  • Subject: Re: java services after installation
  • Date: Wed, 24 Sep 2008 01:39:45 +0200


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.

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


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


Attachment: signature.asc
Description: OpenPGP digital signature




Archive powered by MHonArc 2.6.16.

Top of Page