Re: RFS: snake4 (updated package)
Am Samstag, den 05.02.2011, 14:18 +0100 schrieb Niels Thykier:
> -----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.
As I'm new here it's difficult for me to recognise what reason is
true ;-)
>
> >> >
> >>> > > 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
As far as I can see CFLAGS is used in CCOPT in Makefile and CCOPT is in
the rule for .o files. So it should do something, whatever this
something is.
> 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).
Sure! If I will do it I'll make it as an option selectable before
starting a new game.
>
> > [...]
>
> ~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: