[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Errors found by rpmlint

On Fri, 2005-05-27 at 11:17 -0500, Quentin Spencer wrote:

> 1. wrong-script-end-of-line-encoding
> There are more than 10 of these errors. They are caused by scripts that 
> were created for octave by Windows users. Octave will still read and run 
> the scripts just fine.

If they work properly and are not meant to be modified after installed,
and you're not annoyed by the "wrong" line endings, just ignore rpmlint
on this.  If present, the shebang line in scripts needs to end in a Unix
linefeed to work properly though.

> 2. devel-file-in-non-devel-package
> This error is created by two header files that are included for the 
> benefit of users trying to port C code written to interface with Matlab 
> to work with octave. Is it worth creating a devel package for this? I 
> believe the Debian package keeps these in octave-forge.

If it's only two header files, not worth the split.  Perhaps just ignore
rpmlint here too, but maybe also provide -devel in the package
containing the headers in order to prepare for a future split if more
-devel like files appear?

> 3. non-standard-dir-in-usr libexec
> Several pre-compiled functions are placed in octave's path for these 
> files, which is in /usr/libexec. This is non-standard?

Non-standard as in "not defined in FHS", yes.

>  There sure is a 
> lot of stuff from other packages in /usr/libexec . . . . I also find it 
> odd that rpmlint thinks this is non-standard given there exists a 
> %{_libexecdir} RPM macro.

This macro exists because all "configure" scripts created by autoconf
have a --libexecdir option.  It's not the macro rpmlint is complaining
about, and the existence of a macro does not make any difference wrt.
the stadards compliance of the thing it's defined to anyway.

But like you noted, a lot of packages do install stuff
into /usr/libexec, and the purpose of that dir is at least somewhat well
understood (although many claim that it doesn't really have a purpose),
so it's certainly not the end of the world if your package uses it too.

Personally, I use %{_libdir}/$package (and sometimes a "bin" subdir
below that if there's other stuff in %{_libdir}/$package) instead
of /usr/libexec because of the latter not being a standard one as
defined by FHS.

There was a thread containing more opinions on fedora-devel a couple of
weeks ago, start of thread here:

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]