Re: Objection to change made in debian policy
severity 148941 wishlist
merge 88029 88111
merge 88029 148941
thanks
Hi,
Do you have anything new to add to the previous times this has
come up? Surely you know it is bad form to keep opening new bug
reports every time a notion strikes ones fancy? You lose all the
arguments already made on the issue. Given the fact you had reported
the earlier bug reports as well, I can't see how this could be a
simple oversight; it begins to appear that youa re trying to bypass
the process (and the formal objection in the other reports) by doing
an end run with a new bug report.
Also, surely you are aware of the procedure for policy changes
(if not, please read the documents packaged with the policy manual as
to how to effect policy changes).
>>"Wichert" == Wichert Akkerman <wichert@wiggy.net> writes:
Wichert> Package: debian-policy
Wichert> In version 1.23 of the policy.sgml file Manoj made a few changes
Wichert> that were related to incorporating the packaging manual into
Wichert> policy.
Wichert> Since the packaging manual did not have policy status this
That is a matter of opinion and interpretation. When I took
over the policy groupo from the policy czar, several documents made
up the Debian policy: The packaging manual, the non-packaging policy
manual, and the precursor of the developers reference.
In my opinion, it was never fully ratified as to what parts
were policy -- the poliucy czar had control (Ian Jackson, in the
beginning, this is pre consitution).
I always considered Packaging manual toi have the full weight
of policy.
a) make is an extensible, flexible framewoirk for building
software, and is used by the vast majority of free software
already. It is nice to be able to use the same framework to
hook into package building
b) Make is now a published interface for the rules file, one
may include the rules file in other Make files, one may run
./debian/rules -n -p build to see what exactly is going to
be executed;
c) Makefiles are one simple interface that needs to be
learned, in order to fix a buggy package, or investigate a
bug report, I need know make, I do not need to know shoop,
python, ruby, or perl, I can investigate which target the
error occurred in. If you think it is easy in other
languages, give me a day or so to write a rules file in
perl or C++ to show you how difficult things can get.
d) make can call any other script or binary,as shown by Joey
Hess in the example below.
e) It has worked for us since the brginning of Debian, for
nearly a 1000 maintainers, and 9000+ packages. It is a well
established tradition; and something we can build
upon. There needs to be a strong technical rationale for
willing the change.
Oh, I extend to this report the formal objections I posted to
the idea when it was mentioned in the earlier incarnations. You have
posted nothing new.
manoj
======================================================================
#!/usr/bin/make -f
# Look, ma, I'm policy compliant!
%:
tail -5 debian/rules | perl - $@
ifeq (foo,bar)
sub endif {}
for (1..10) {
print "hello, world: $ARGV[0]\n";
}
endif
The lesson might be that trying to legislate good taste will never work. :-)
see shy jo
======================================================================
--
What do you call it when someone rubs a Volkswagen van on your head?
A Fahrvergnoogie.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: