Re: RFS: snake4 (updated package)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2011-01-23 16:05, michael wrote:
> [...]
Hey,
Sorry for the late reply. I am taking the liberty of answering this one
first.
> Last questions : Is it a MUST to make those suggested changes? And if
> not, what's next now?
None of these suggestions in my last email were a *must* on my part,
mostly because I intend have you contact the Debian Games Team (as I
mentioned in my first email). Due to a lack of experience with games
packages I do not feel good about being the sponsor of game packages.
Beyond what is required by the Policies etc. (and defacto standards
where policies are outdated) you and your sponsor decides what are
*must*, what are *should* and such.
Also I suspect that you have been reading Neil Williams "Sponsoring
requirements", since you have been made a -12 and a -13 revision. It is
entirely possible that your sponsor will want you to merge these two
into a single -12 entry. But that entirely depends on your sponsor.
Regarding the next step: well,
>> >
>> > I would also like you to clean up d/rules. At least remove/merge
>> > uninterested targets and comments. Please also either fix the "noopt"
>> > build option or remove the code for it (fixing it probably requires
>> > patching upstreams Makefile, since it does not react to CFLAGS).
>> > Personally I prefer things like the debhelper "tiny rules"[2] with
>> > override targets (or cdbs, but I have less practice with it). These
>> > styles have the advance of hiding the "standard stuff", making the
>> > "non-standard" parts more visible.
> I'm not sure if it's worth changing to cdbs and/or quilt right now for
> only 4 small changes (I use it for an other adopted package - snacc -
> right now, so it's not a question of skill).
> I removed that dh_desktop line - that's o.k. for I added the #, but I
> can't see the necessity of changing the other things or removing
> comments. It was o.k. all the time so far and is doing no harm. I also
> like to have some comments, even if they remain from the initial
> conversion to a debian package.
>
I am fine with you having your own opinion on things like this. Since
you will be working with the package the most, I would /personally/ be
okay with keeping these particular 4 small changes directly in the diff.
As for the unused parts of the rules file. Truly the current rules
file is functional as it is; also I am perfectly fine with you keeping
the comments in the file you need/want. If they help you as a
maintainer, then by all means keep them.
What I do not understand is; why do you want to keep the
configure{,-stamp} targets? They do nothing but touching a file and
their existence are not required by the Debian Policy. Why do you leave
the check for whether the Makefile exist being running $(MAKE) clean?
The makefile is not removed by its own clean target. This rules file
look like something geared towards a package using autotools.
Finally there is this part, which I asked you to look at:
ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0
else
CFLAGS += -O2
endif
I do not see any changes to it, nor to the upstream Makefile. Does this
work as intended? That is, will
DEB_BUILD_OPTIONS=noopt dpkg-buildpackage
produce an unoptimized package? As I recall I came to the conclusion
that it probably did not work, but feel free to correct me if I am wrong.
>> >
>> > When you clean up the rules file, please bump debhelper to at least 7.
>> > if you go with "tiny rules" with overrides, you will need a
>> > Build-Depends on debhelper (>= 7.0.50~) - but the compat is still 7 in
>> > this case.
>> >
> Why that? Even lintian was only requesting (on that mentioned snacc
> package W: snacc source:
> package-lacks-versioned-build-depends-on-debhelper 5) to change from >>4
> to >>5. On the other hand actualised lenny is using 8.0.0~bpo50+2, so
> why not change to 8, for I haven't checked against older versions and I
> do NOT intend to do so?
> Just to be complete : this change has to be made in the control file,
> not in rules.
So, starting with Lintian here. The Lintian warning you saw is about the
package having a Build-Depends on debhelper 4, when the package said it
used debhelper 5 features (in debian/compat). Since compat 5 is not
strictly deprecated, Lintian will not warn about its usage.
As for debhelper in lenny; lenny has 7.0.15 - the version you are seeing
is debhelper in lenny-backports. There is a difference between the two.
I am willing to believe that snake4 is an unlikely candidate for
security or (old-)stable uploads.
I see no reason why you cannot use debhelper 8 instead of 7 for snake4
actually. I have just been accustomed to using compat 7, so the new 8
compat went past me. :)
> [...]
>
> Kind regards
> Michael
>
>
If you have any questions to the above, feel free to write back on list.
If I do not reply within four days (like I failed to do this time), feel
free to ping me in private as well.
Else I would recommend you send an RFS to the Games Team. :)
~Niels
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJNSeqtAAoJEAVLu599gGRC47IQAJuMLVmr0GRkz3Cxb14mcO3c
QPIO/dJx0smtZ0J6vX1wteHfH0Fo3Z9avzE2ryu7QgGOtDGwPVLhD9fWq0+Ad3F/
vus3IrSDmNRbmpRhRR/Ja8URswHt1pF4sA42343DcmUgscNP8I3JSpB4yCPeeQut
Kfgva7UZmeOgri4gnAuCJL9Kp8XGSKsPWWSaHjI6JdlANAv4/gJuLpHYD8/8DPiA
lYUBDe+GXB72YU9VrRai8t5MZkoOx0deJaHeJSaM/5mpfBbrraMBT2Kv1qxZ02F8
ydUELFx/odDmQS8Nv/7zD8qvSjNIG/m1kscOwKvwounf8UBhoE33JdQAOEo1ihAB
MPBt2YUQSQhTcGxSDWLw2WP/UFkppAvSTil3cB14qkF525wNi261RUGNmG9yPyms
aRXErM6yGKfNKDSzJvivjeeA40WST3/tUfwoMMIy7UpgyRXwlEZlf+PCoz7mYzIx
lqQps+gNWDvHIepFAHwx1/FJVPsRiNFV/gmitRpYHF4CTSbljeiGiGkWN5HYXVkA
mStw6vfxRLpsDMYnKX/cBCE26gIwBV0cvFukkKOD9GeR0daPT7XhId+cIrrRVd1q
Cae1sw5U16HhrGOudVJHnbly4V38DPKtLy0OUqC1Cpr4fetdreBEYx7atRg08p2x
zwh2YoYd9QnFIwrFhLb3
=hWF9
-----END PGP SIGNATURE-----
Reply to: