Re: RFS: snake4 (updated package)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2011-02-05 13:39, Michael wrote:
>> On 2011-01-23 16:05, michael wrote:
>>> > > [...]
>> >
>> >
>> > Hey,
>> >
>> > Sorry for the late reply. I am taking the liberty of answering this one
>> > first.
> That's o.k. although I feared I had picked some wrong phrases for
> englisch is not my native language...
>
Yeah, silence tend to give that impression; though in my experience it
is usually more of a sign on people being busy or lost track of it.
>> >
>>> > > 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.
> I want to do that next, but I wanted to wait until squeeze is out(this
> weekend). Will a RFS mail to debian-devel-games@lists.debian.org be the
> correct way to do so ?
>
I think an RFS on that list would be okay (at least others appear to do
the same). Most of the documentation I can find sort of assumes that the
package and the maintainer of the package is a part of the Games Team.
>> >
>> > 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.
> I'm sorry, but you are wrong. I just read the requirements on your hint
> (thanks a lot, because that's one reason, why I want to get involved
> here) and found that similar ideas lead me to the same result.
>
:)
>> > [...]
>> >
>> > 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.
> I must admit that make (and automake etc.) are my least familiar tools.
> Actually I'm glad, if I can add necessary changes without destroying the
> old parts. For I adopted that stuff not knowing what the former
> maintainers thought by keeping that code I would stay on the principle
> "never change a running system", but if it's a general principle to move
> every unneeded thing out of rules and makefile I surely can do those
> changes...
>
It is good to have a "never change a running system" view in some cases,
since it tends to avoid regressions. On the other hand that view alone
also lead to staleness.
> About that CFLAGS stuff I don't know, if it's ever needed for debian. I
> haven't used it by now, but I think it was (is) intended to use for
> debugging purpose (gdb or ddd). I have the idea to change snake4 in the
> way not crashing the snake on the borders, but to leave and entering at
> the opposite border. When doing this (maybe in the future) I can check,
> if I get an not optimised program by setting those option.
>
I am also perfectly fine with you simply removing the "noopt" CFLAGS
stuff. The problem with keeping it is that it implies that the package
supports it, when it really does not. That being said, it would be great
if the package eventually was patched to support using CFLAGS/LDFLAGS.
The reason is that it would allow Debian to later change the default
build flags and then snake4 would "work out of the box" with the new
build flags. Currently Ubuntu is building with different linker flags
then Debian and it is possible that Debian in the future would adopt these.
As for changing the rules of snake4, perhaps you debate it with upstream
(assuming upstream is still available) or at least make it optional.
Some of our games may very well prefer the walls (because it makes it
more difficult/interesting).
> [...]
~Niels
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJNTU4WAAoJEAVLu599gGRC5i4QAI/wA18Zf4CJCRULyo8c29jD
LL16Q7H3akfGccNSPn1B9RrWJF80iWk+X1UjkMSLiivjnY0O3iSlLgH64Tl4pTnA
ZdRZsnvPtbsWI5BZ0lS3ewn4yxcUdZTvVJwwAcqdVYUfJbgcixnJOOb9JfASRUm7
FV4LtzSUFvUwMzUAhnr/0qKvcxlG6+5hAVXcXPoBa1Cby9qYyzRcoJLpHJuFRcWI
DbDEuwBiWer+w6ipBNaceMQnXQxrBSufC1u3hrWHQIGrP0puIb29DyUoSB1bKX64
gkKtVDaiKDwMp2GBeOEnYJm5ddjr31ORgGshGq7TCISIrOoQBS7UP9FZi5CSuTdp
RK2xcLu7C77oNWBjDb6TqZ3cYTcMEk7tp77l54iqNjqB3d47WLdpqKDF/6UqY5kA
LThSzLzcTQ2E0odDl1iVE1RyMajWVZ7jFXEu9G7lkiAlaWSsW9ATQgX5cCbN/4uv
+C5A7cJvG8/Oy1MzlUPSQeL98bDNatFXojGPwpyULzAbrpzAW+CnWyz20E8IbdLF
IMkDAd9Rxa4x3e+mk3bExKAZuovFxfaymVOW4l3UXgbEl0RD48drMu4TX/6ebf/m
jbiWzA4L804TxGfjegfbtqHIPUjKXOIuIR1vw3LH1rOAmpi34rBf+l+AqJDG/jxu
cLkWA4nQOfX8YExcLya2
=WLD3
-----END PGP SIGNATURE-----
Reply to: