Skip to Content.
Sympa Menu

perfsonar-dev - Re: [pS-dev] Re: java services after installation

Subject: perfsonar development work

List archive

Re: [pS-dev] Re: java services after installation


Chronological Thread 
  • From: Jochen Reinwand <>
  • To: Gijs Molenaar <>
  • Cc: Roman Lapacz <>, Verena Venus <>, Cándido Rodríguez Montes <>, Maciej Glowiak <>, Stijn Melis <>, Michael Bischoff <>, "" <>,
  • Subject: Re: [pS-dev] Re: java services after installation
  • Date: Wed, 24 Sep 2008 09:21:07 +0200
  • Organization: DFN Verein

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:

http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/execstuff.html
17.1.8. Installable applications

What you can read here implies that the perfSONAR usage of /opt is OK.

But why not take a look at the Filesystem Hierarchy Standard (FHS) that is
really responsible for the filesystem hierarchy of a Unix based distribution
that is also referenced by the LSB. Here is the /opt part:

http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES

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.

greetings,
Jochen

On Mittwoch, 24. September 2008, 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.
>
> 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/packagin
> >g/
> >
> >
> > https://svn.perfsonar.net/svn/perfsonar/trunk/geant2-java-sql-ma/packagin
> >g/
> >
> >
> > Roman



--
Jochen Reinwand, DFN-Labor
Friedrich-Alexander-Universität Erlangen-Nürnberg
Regionales RechenZentrum Erlangen (RRZE)
Martensstraße 1, 91058 Erlangen, Germany
Tel. +49 9131 85-28689, -28800, Fax +49 9131 302941

www.win-labor.dfn.de



Archive powered by MHonArc 2.6.16.

Top of Page