Re: package lint suggestions
2008/5/3 Yaakov (Cygwin Ports): > Charles Wilson wrote: > | * 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: > > "big job" is an understatement; google "gentoo collision-protect" to get > an idea. Not so big. I've added that feature to collision-protect subpackages within cygport. To check against all package we'd need just the /etc/setup/*.lst.gz lists. -- Reini
Re: package lint suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Brian Dessent on 5/2/2008 7:55 PM: | | Alternatively, if bash were to directly install both /bin/bash and | /bin/sh instead of copying the latter in a postinstall then we would no | longer have this requirement. For the 1.7.0 release area, I'm planning on doing just that. In the meantime, the upstream maintainer just published some more bash patches, so I have a release to do anyway next time I have the time available. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgb6IIACgkQ84KuGfSFAYBxrACg0hm6ec+YwrFp8+vO4wNJLPpY ib4AoLAIxUg+jZv6xrDPtZlofZKX14tZ =w0Gx -END PGP SIGNATURE-
Re: package lint suggestions
"Yaakov (Cygwin Ports)" wrote: > | - contains postinstall/preremove script without requiring bash (this > | matters for the order in which scripts are run) > > Isn't that an overkill; bash is in Base, after all. It matters for the order that the postinstall scripts are run, because that order is determined by the topo sort on the 'requires:'. The bash package installs /bin/bash.exe and copies that to /bin/sh.exe in its postinstall if there is not already a /bin/sh.exe that isn't ash. This means if you simultaneously install bash and some other package that has a postinstall script (as during a new installation), and if that other package doesn't list bash in the 'requires', then there is a chance that the other package's postinstall will be run before bash's postinstall, and consequently that postinstall will fail with "invalid interpreter" if it starts with "#!/bin/sh" as postinstalls are always invoked with "/bin/bash -c" which honors the shebang. But if the package 'requires:' bash then its postinstall will always be run after bash's postinstall, avoiding the issue. We have historically lucked out here for several reasons: - many postinstalls don't have a shebang, or explicitly list #!/bin/bash - outside of the case of a fresh new install, /bin/sh tends to always exist - the bash postinstall tends to be near the front of the topo order anyway (So I suppose technically the lint rule should be that if you have a postinstall that stats with "#!/bin/sh" you must 'require:' bash.) Alternatively, if bash were to directly install both /bin/bash and /bin/sh instead of copying the latter in a postinstall then we would no longer have this requirement. Brian
Re: package lint suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Christopher Faylor wrote: | - Existence of /usr/man, /usr/doc rather than /usr/share/man /usr/share/doc. Also /usr/info. | - Missing /usr/share/doc/Cygwin/* (probably a warning). Most of the time when building foo/libfooX/libfoo-devel packages, there is only one Cygwin README, for foo. | - setup.hint has overly long ldesc. Is ldesc actually used for anything? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkgbutMACgkQpiWmPGlmQSO7+ACeLm7hODJid1UyytTa78SEJMyP fNcAoMffSIspZeRj19OUgZKCwUiMCMcR =RcLz -END PGP SIGNATURE-
Re: package lint suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Brian Dessent wrote: | - setup.hint missing any of: sdesc, requires, category Some -doc packages don't have any requires. | - contains postinstall/preremove script without requiring bash (this | matters for the order in which scripts are run) Isn't that an overkill; bash is in Base, after all. | - installs conf file directly into /etc instead of putting it under | /etc/defaults/ and installing it with a postinstall/preremove only if | the user hasn't customized it Not everything in /etc is meant to be customized, at least not in place. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkgbuI0ACgkQpiWmPGlmQSOVjgCg+TDhY7kXVFaV1tYJIkctdfEQ WEoAoLF4wSobCEK3tRuleA+pinVbSvBi =jk+R -END PGP SIGNATURE-
Re: package lint suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: | 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// HUNDREDS of packages have dlopen'ed modules: $ find /usr/lib -name '*.dll' -o -name '*.so' | wc -l - 5173 - So I'd say scratch that one. | * /usr/info/dir and /usr/share/info/dir Common collision-protect issue, and /usr/info shouldn't be used at all. | * odd locations for LC_MESSAGES directories (e.g. other than | /usr/share/locale/*/? | | * Eventually -- not yet -- disallow /usr/X11R6/ And /usr/local/. | * 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: "big job" is an understatement; google "gentoo collision-protect" to get an idea. | /usr/lib/charset.alias | /usr/share/locale/locale.alias | libbfd.a | libiberty.a How common are the last two? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkgbtZMACgkQpiWmPGlmQSPv4wCg4zYVbKzuVZPychx61+wOkVKI 808An1IvEmgVfaj0O/tan3kXlbqmMSkz =cC1E -END PGP SIGNATURE-
Re: package lint suggestions
Warren Young wrote:
- Missing README
There's no real requirement for that, even if your package DOES have a
cygwin-specific README. It's not like txt documentation needs a "source"
to satisfy the GPL or something.
and setup.hint in the -src.tar.bz2. (No cygwin.patch)
And there's definitely no call for this. I only include 'em because
cygport makes me do that. But here's something that bugs me:
If I create a new package, but want to put it in "test" for a week or
two -- then I can't really use the setup.hint *in* the package when I
upload it to sources. The one *in* the package doesn't know that it's
going to be in 'test' for a week, and I certainly don't want to create a
brand new -src package so that I can update the internal setup.hint when
I /do/ move it from 'test' to 'curr'.
So, except when I am *first* uploading a *brand new* package to sources,
I usually do this:
$ cd foo-1.2.3-1/dist
$ find . -name "setup.hint" | xargs rm -f
$ tar cvf ../../foo-1.2.3-1.tar
and upload just my tarballs, and not the setup.hints ('cause they are
already up there. If they need changing, I'll do that in situ.)
Just because cygport forces you to work in one way is no reason to
assume that the overall cygwin project has requirements quite that
restrictive. (And besides, if you ARE using cygport, IT will warn you
about those two issues. But IMO it's your choice to obey or ignore those
cygport warnings)
--
Chuck
Re: package lint suggestions
On Fri, May 02, 2008 at 04:56:07PM -0600, Warren Young wrote: > Christopher Faylor wrote: >> I'd like to get a list of things to check for. > > - Missing README and setup.hint in the -src.tar.bz2. (No cygwin.patch) There's no requirement that setup.hint be in the -src.tar.bz2 or that there there should be something called cygwin.patch. I'm not terrifically concerned about the source tarballs actually. I just want the standard thing that people install to be as problem free as possible. cgf
Re: package lint suggestions
Christopher Faylor wrote: I'd like to get a list of things to check for. - Missing README and setup.hint in the -src.tar.bz2. (No cygwin.patch)
Re: package lint suggestions
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// 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. > > Ppppbbtt! :-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
Re: package lint suggestions
On Fri, May 02, 2008 at 12:52:58PM -0700, Brian Dessent wrote: >Christopher Faylor wrote: > >> I know that I'm missing some obvious stuff here. What am I missing? > >- setup.hint sdesc that starts with the package name > >- setup.hint missing any of: sdesc, requires, category > >- sanity checking for setup.hint category - I don't want to say hardcode >a list of allowed categories, but it would be nice to catch typos and >prevent accidentally creating new categories. > >- contains postinstall/preremove script without requiring bash (this >matters for the order in which scripts are run) > >- man pages not gzipped (this would certainly have to be a warning only >as many packages don't do this) > >- installs conf file directly into /etc instead of putting it under >/etc/defaults/ and installing it with a postinstall/preremove only if >the user hasn't customized it > >- two packages owning the same file - this would require some kind of >global state (e.g. a tied hash with a backing dbm file) in the lint >script so it may be prohibitive, but it would be good to catch two >packages that accidently overlap Good stuff. Thanks. If I write a perl framework to handle things like this maybe we can get some volunteers to augment this tool. cgf
Re: package lint suggestions
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// - setup.hint has overly long ldesc. Ppppbbtt! :-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? * /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. -- Chuck [*] I explicitly patched inetd to ignore files in /etc/inetd.d/ that began with a '.', for precisely this reason. I used cygport's keepdir feature to retain /etc/inetd.d, but then inetd keep trying to parse the empty /etc/inetd.d/.keepdir-inetutils file as a configuration script. However, I *almost* think that's a security issue: there shouldn't be configuration scripts -- used to set up internet servers, no less -- that are hidden from view, where the sysadmin might miss them. I don't ordinarily do ls -a in /etc/...
Re: package lint suggestions
Christopher Faylor wrote: > I know that I'm missing some obvious stuff here. What am I missing? - setup.hint sdesc that starts with the package name - setup.hint missing any of: sdesc, requires, category - sanity checking for setup.hint category - I don't want to say hardcode a list of allowed categories, but it would be nice to catch typos and prevent accidentally creating new categories. - contains postinstall/preremove script without requiring bash (this matters for the order in which scripts are run) - man pages not gzipped (this would certainly have to be a warning only as many packages don't do this) - installs conf file directly into /etc instead of putting it under /etc/defaults/ and installing it with a postinstall/preremove only if the user hasn't customized it - two packages owning the same file - this would require some kind of global state (e.g. a tied hash with a backing dbm file) in the lint script so it may be prohibitive, but it would be good to catch two packages that accidently overlap Brian
