Spec Name or Url: http://home.zonnet.nl/jwrdegoede/dumb.spec
SRPM Name or Url: http://home.zonnet.nl/jwrdegoede/dumb-0.9.3-1.src.rpm
IT, XM, S3M and MOD player library. Mainly targeted for use with the allegro
game programming library, but it can be used without allegro. Faithful to the
original trackers, especially IT.
As usual this is a very often used allegro addon lib used by quite a few games
I'm planning on packaging. Thanks in advance!
Looks like Jason beat me to it. :)
This package has an incredibly poor license. What's the point of stating a
bunch of meaningless conditions and then specifying that you can ignore them if
it makes the package GPL incompatible? In any case, it's clear that the package
is explicitly GPL-compatible, and it's pointless to try to come up with any
other statement of the license. So "GPL-Compatible" seems reasonable, although
"Dumb license" is tempting.
Why are readme.txt and release.txt part of the -devel package? They seem to
contain useful end-user info, and so it seems to me as if they should be in the
main package. There are a couple of other files under docs that could probably
be considered to be non-developer documentation as well (modplug.txt, faq.txt).
rpmlint only complains about the license:
W: dumb invalid-license GPL-Compatible
W: dumb-devel invalid-license GPL-Compatible
* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written, and uses macros consistently.
* license field matches the license, as it is.
* license is open source-compatible and included as %doc.
* source files match upstream:
* package builds in mock on x86_64 and i386.
* BuildRequires are proper.
* shared libraries are present; ldconfig is called as necessary.
* package is not relocatable.
* package does not create any directories.
* no duplicates in %files.
* file permissions are appropriate.
* %clean is present.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* headers are in a -devel package.
* no pkgconfig files.
* unversioned shared library links are in the -devel package.
* -devel package has a versioned dependency on the base package.
* no libtool .la droppings.
* not a GUI app.
* Package owns no files that are owned by other packages.
Just the issue of the readme.txt and release.txt to discuss.
About readme.txt, a quote from the Introduction part of it:
"This file will help you get DUMB set up. If you have not yet done so, please
read licence.txt and release.txt before proceeding. After you've got DUMB set
up, please refer to the files in the docs/ directory at your convenience. I
recommend you start with howto.txt."
And then it continues on howto compile under Windows, Linux, etc. I guees I
should have completly ommited it, atleats that is what I would like to suggest
now. But imho this is most defenitly not end user documentation
About release.txt this is basicly a changelog and indeed belongs in the main
About modplug.txt this is written with mod-file creators as intended audience
and warns them tio shy away from non IT compatible modplug extensions, I don't
know where this belongs, its basicly a polite rant against modplug, maybe we
shouldn't include it at all?
About faq.txt 95% of the questions in here are about using the library in other
programs. The one question which is not once more is intended for mod-file
creators and is again about modplug IT incompatibilities.
So I suggest for the docs:
-mv release.txt to the main package
-leave faq.txt in the -devel package
I'll attach a new spec with these changes (sorry no upload to my isp hosted page
Created attachment 126213 [details]
The thing about readme.txt is that it also has a feature list and info about
where to get music that it can play as well as a bunch of developer
documentation. It's also the only documentation for the three executables which
are included with the main package.
We'll have to accept that there isn't a proper separation of user and developer
documentation for this package, but if there's one file that actually describes
what on earth the software does, it's readme.txt.
If the intent of the package isn't to supply the three executables, perhaps it
would also be reasonable to drop them and rename the package to "libdumb".
Created attachment 126233 [details]
Ok, I see your point, readme.txt added to the main package as requested, see
the attached new specfile.
Thanks, imported and build, closing.