Re: package lint suggestions

[Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>]

On Fri, May 02, 2008 at 06:28:57PM -0400, Charles Wilson wrote:
> Christopher Faylor wrote:
>> As part of my effort to allow maintainers to upload their own packages
>> I am thinking of finally writing a package lint script which checks for
>> known problems in packaging.
>
>> - Empty directories.
>
> I'm not sure this is a good idea.  With cygport, empty directories are 
> automatically removed, but sometimes -- like today's re-release of 
> 'alternatives' -- that's a problem.  Alternatives needs the 
> /etc/alternatives and /var/lib/alternatives directories -- but doesn't 
> actually put anything there itself, on first install.
>
> Obviously, there are two ways to solve this, so that "empty" directories 
> aren't really empty.  The cygport way is to insert a .keep-pkgname file 
> into the "empty" directory [*].  Or, you could use a post-install script.
>
> Anyway, if 'empty dir' is made a lint error, expect a number of old 
> packages -- obviously, non-cygport ones, all -- to trip on that one.
>
>> - DLLs not installed to /bin or /usr/bin.
>
> Not an error.  dlopen'ed modules -- such as m4-2.0 and perhaps 
> ImageMagick/GraphicsMagick -- might be named ".dll" but will live in 
> /usr/lib/<somewhere>/

The purpose of the tool is to handle common error conditions.  If *some*
packages fall outside of the norm then there has to be a way to handle
those packages.  We can't just ignore common errors because a small
subset of packages have a valid reasons to do things in an unusual way.

>> - setup.hint has overly long ldesc.
>
> Pppphhhhbbtt! :-P
>
> * If the cygwin README exists, should we check its contents, e.g. for the 
> version string itself (as an indicator that the README was updated for this 
> particular release)?  Maybe other "required" information?

That would be nice.  I often forget to update that.

> * /usr/info/dir and /usr/share/info/dir
>
> * odd locations for LC_MESSAGES directories (e.g. other than 
> /usr/share/locale/*/?
>
> * Eventually -- not yet -- disallow /usr/X11R6/
>
> * The "check all packages for file conflicts" is a big job -- and will get 
> lots of false positives whenever a package is split up into -devel/lib/bin 
> pieces.  However, there are a few files that commonly conflict between 
> packages:
>
> /usr/lib/charset.alias
> /usr/share/locale/locale.alias
> libbfd.a
> libiberty.a
>
> Maybe there should be special checks just for these common areas of 
> conflict.

I expect that this will evolve over time.  OTOH, maybe I should just
start with an MRI of Volker's brain and try to map that into perl.  That
would probably capture just about everything.

cgf