Le 2012-06-05 20:57, intrigeri a écrit :
Here is a first, quick review.
Thank you.
The whole thing is arch:all, but some shell functions require a Linux
kernel shouldn't bilibop-common have a versioned dependency on Linux
kernel >= 2.6.37 (needed by backing_file_from_loop), and be
arch:linux-any instead?
I don't know exactly how to do a versioned dependency on the kernel.
With a list of alternatives of *generic* (meta or dummy) packages?
like:
linux-image-486 (>= 2.6.37) | linux-image-686 (>= 2.6.37) |
linux-image-686-bigmem (>= 2.6.37) | linux-image-686-pae (>= 2.6.37) |
linux-image-amd64 (>= 2.6.37) ... linux-image-itanium (>= 2.6.37) |
and so on with 'powerpc', 'sparc64', 'sparc64-smp', plus the 'openvz'
and 'vserver' variants, the list is very long... Should I give an
exhaustive list of kernels, including all exotic achitectures, some
of them being relative to computers having even no USB, FireWire or
eSATA ports (but I don't know which), or what?
I'm looking for another package that could provide me an usable
example of such versioned kernel dependency, but I fail.
I've tried with just 'linux-image (>= 2.6.37)', but lintian sends a
warning: virtual-package-depends-without-real-package-depends. Can
I override it (with override_dh_lintian in the rules) ?
I think I need help.
Additionally, changing 'all' by 'linux-any' leads to the creation
of architecture dependent binaries (formally, by their names), but
with exactly the same contents: shell scripts, udev rules, manpages
and other plain text documents.
So, I'm not sure that it is the best way. Maybe, for bilibop-common,
Architecture: linux-any, and for the others, Architecture: all ?
Do you think a NOTE in the extended description and/or in the README
could be sufficient ? (due to the fact that bilibop-* already depend
on base-files (>= 6.4) and could be available from Wheezy or even
later, is there really a chance that it can be installed on systems
with a kernel older than 3.0 ?)
Quotes such as in "« disk »" are no international symbols, and I've
seen English native speakers misinterpret those.
Fixed.
You want an URI to a versioned copyright format:
Format:
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
(catched by lintian --pedantic).
Fixed.
Any Vcs-Git / Vcs-Browser field? If you have none ready, I suggest
setting up a Git repository in collab-maint on Alioth.
I will think about it, later (I have to learn git before).
Given the Maintainer is a collective email address, we need at least
one human listed in the Uploaders: field (Debian Policy §3.3) -- note
that this field has nothing to do with who actually sponsors the
uploads; either put yourself, a co-maintainer, or the first sponsor
if
they are willing to take the responsibility to act as co-maintainers.
Fixed.
Why does bilibop-common's postinst and postrm run update-initramfs?
Ooops... yes, this is an error (remaining files from old version).
Fixed.
The debian/changelog entry must close the ITP bug.
OK
The debian/rules header about "Sample debian/rules that uses
debhelper" should be removed.
Removed.
Why the need to disable override_dh_pysupport by hand?
The need ? None. Removed
Cheers,
quidame
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2c2ad8eafefa26d173ed08224142b...@poivron.org
