lsbinstall (was: Announce: LSB 3.0 RC1 is out)

Hello,

Wichmann, Mats D wrote:
>LSB 3.0 specification Release Candidate 1 is now
>available for review at:
>http://refspecs.freestandards.org/lsb.shtml#LSB_3_0_0
>  

**** LSBINSTALL ***
http://refspecs.freestandards.org/LSB_3.0.0/LSB-generic/LSB-generic/lsbinstall.html

Once again regarding lsbinstall (half of it is already covered by 
several existing bugs, for those I hope to spun some discussion; for the 
others issues one probably should fill some bugs).

- font
I still don't understand what is ment by "install"? I assume it means 
(a) copying the file and (b) creating the needed files like fonts.scale, 
fonts.dir, encodings.dir, fonts.cache-1 etc.
Is there a minimal set of font types which have to be supported? (Type 
1, truetype, pcf, opentype etc.?)

- init
All LSB 1.x and 2.x complient Linuxes have /etc/init.d/ to which 
LSB-[12].x-complient init scripts have to be installed.
I don't see any reason to change this in LSB 3. This prevents 
package-based tracking of the init script, creates extra files (the 
not-yet-lsbinstalled init file has to be somewhere) and makes LSB-1.x- 
and 2.x-complient applications incompatible with 3.x. (For config file 
vs. not, see below.)
CAN SOMEONE PLEASE TELL ME THE ADVANTAGE OF lsbinstall COMPARED TO 
INSTALLING IN /etc/init.d/ DIRECTLY?
(If there is a good reason, I don't mind "lsbinstall -t init". ;)

- profile
Similar to init: What is the advantage of copying the file around 
instead of putting it into /etc/profile.d/ directly (using the LANANA 
name space)? The advantages are the same as with init.d
(I still would like to see a note stating that *.csh may also be 
installed into /etc/profile.d/, even if the behaviour is undefined; but 
I'm probably out of luck here. And: no, I don't want to specify the 
C-shell syntax, but most C-shell scripts - esp. those which set 
environment variables - simply work everwhere. And /etc/profile.d is 
primarly for environments variables as it is sourced by the login shells 
of all users. [Well, except for *csh users with the current definition.])
By the way: It nowhere tells what should happen distributionwise with 
the "profile script". I assume that it is ment to be sourced by login 
(posix-type) shells (e.g. using in /etc/profile:  for I in 
/etc/profile.d/*sh; do . "$I"; done).

- crontab
Similar to init and profile: What speaks against /etc/cron.d/ ?
Or is this only ment to do a "/etc/crond reload" (which usually does 
nothing since crond checks automatically for changes)?

- menu
What is a "a desktop menu entry"? You probably mean
http://www.freedesktop.org/wiki/Standards_2fdesktop_2dentry_2dspec
but you never say so.

General observations

a) Error handling
What happens if e.g. a menu/font file already exists? Will it be 
overwritten or does the installation fail; if so, with which error code? 
Analogously for removing: Is removing a non-existant file an error or not?
(Other error conditions are covered.)

b) Do the filenames (esp. menu and font files) need to be unique, i.e. 
use the LANANA prefixing or not?

c) (At least my) /etc/services has the syntax:
"%s  %d/%s  %s  # %s"  service_name port tcp_or_udp alias  description
Currently, descriptional comment is not supported, which might be 
helpful, actually.

d) man
I hope this is only ment to check the permissions and to update the 
apropos database not to copy the man page around. Contrary to 
/etc/profile.d/ and /etc/init.d/ the location is indeed defined in the FHS.
If it does not copy the actual man file (as I hope), will it add 
`dirname /opt/<provider,package...>/{share,}/man/man*/myman.*` to the 
manpath?

e) %config - files marked as configuration file
Many distributions regard profile scripts, init scripts and inet files 
(some also menu files) as configurations files which have to be treated 
more carefully in terms of removing and overwriting. Both DEB and RPM 
which are classically used to install those files take this into account.
RPM moves _changed_ configuration files to $file.rpmsave when 
uninstalling and saves new files as $file.rpmnew instead of 
overwritting. Should something like this be done here as well?
(For profile and init scripts I want to use RPM files / the package 
installer anyhow. But for inet files this is still an issue since they 
have to be installed by a script due to the inet vs. xinet difference.)
(Debian even regards /etc/services as config file and disallows to 
"mess" around with it; we want to do so, but for removing one should 
check whether the service name actually matches, before removing.
 [Debian package maintainers can simply ask for adding the line to the 
central file, something ISV cannot do, i.e. we need -t service].)

f) Disabling vs. Installing
For init scripts there is a mechanism at place which allows the files to 
be installed -- either as package :-) or via lsbinstall :-( -- and 
independently from that to be enabled or disabled ({install,remove}_initd).
Similarly, something should be done with inet files (due to the 
ined/xinet differences one needs a script for installing, unfortunally); 
there should be a possiblity to enable/disabling them without needing to 
remove/install them. In addition the question is: Should the (x)inet 
daemon receive a HUB if a ined is enabled/disabled?
One probably also wants to be able to query whether a script is dis/enabled.

g) Query package
Shouldn't there be a defined output format? I'm thinking of having the 
possibility to obtain the version of an installed package. Note that 
e.g. RPM allows to install a package multiple times thus rpm -q 
<package> may return more than one line (with (not necessarily) 
different versions).
Format could be "%s %s %s\n" $packagename $version $undefined or simply 
"%s\n" $version or ...

h) Package install
With regards to e.g. configuration files, RPM (and DEB) behave 
differently if one does an update or a remove and then a new install. If 
I want to do an update, can I simply do "-t package *.rpm" or do I need 
to uninstall first?
Currently, the syntax is "lsbinstall -t install <one_operand>", I think 
one should allow for more than one operand which helps to reduce some 
dependency problems and may speed up the installation. Is there any 
argument against this?

Tobias

PS: I withdraw my question for "info" I asked for in a bug a while ago, 
since the "info" command is not required (so far) by the LSB and is not 
widely used (except for GNU command-line tools). Besides it poses 
name-space problems as by default only /usr/share/info/ is used for all 
files.

PPS: I claimed that init.d was part of the FHS, which is actually not 
the case; however, there exists a bug which suggest the addition. It was 
turned down for 2.3 since not all Unixes do so (e.g. not all *BSD), but 
the bug remains open to reconsider for 2.4. 
http://bugs.freestandards.org/show_bug.cgi?id=37
The LSB, however, requires /etc/init.d/ by requiring that init scripts 
have to be installed into /etc/init.d/ and are then activated by 
install_initd /etc/init.d/filename. In addition, /etc/init.d/ is common 
practice for all current Linux systems (except some embedded onces) - at 
least those I know of. (Other places used were /etc/rc.d or 
/etc/rc[S0-9].d/ and /sbin/init.d/, some of which are still used by some 
Unixes and by [some] *BSD.)