Bug#31645: PROPOSED] Explicitly making the Packaging Manual a Policy Document
Hi,
>>"Joey" == Joey Hess <joey@kitenet.net> writes:
Joey> I read all these. Most were sidetracked into the question of
Joey> the Developer's Reference. The only one I could find that
Joey> mentioned the Packaging manual was the last one, which did say,
>> On the other hand, the Packaging manual seems an excellent addition to
>> the Policy Group's duties, assuming they are up to the task.
Joey> Which I have no problem with, but does not imply that it become
Joey> policy just because the same group maintains it.
I made a proposal, asking which documents were to be
considered policy. Christian considered all these three documents
policy, remember, and I proposed all three. There were active
objections to including the developers reference, but none for the
other two.
The maintainers of the pther packages were then asked to
relinquish control, on the mailing list, and they did so. All this
while there was no objection.
Joey> If this change has already happened, it slipped in with most of
Joey> the developers unaware of it, and without them considering the
Joey> implications of the change, and I will try to get it changed
Joey> back.
Please feel free. You need to get a vote in the policy group,
or get a general resolution passed.
>> As it is already policy, I would like to screen out all the
>> things that should be thrown right back out.
Joey> Unfortunatly, that's on the order of 50% of the document.
I think you exaggerate.
Joey> Do you really believe that the mechanics of how
Joey> update-alternatives and dpkg-divert work is policy? Or the
Joey> details of exactly how dpkg calls the maintainer scripts? Or
Joey> exactly which arguments dpkg-buildpackage takes? Or the details
Joey> of converting an old source format package? It's all in there..
I see no harm in most of it, no. Espescially the bit about how
and when the maintainer scripts are called; that is current Debian
policy. Given the need for backwards compatibility, that is unlikely
to change. Now, the interactions have become policy, and future
implementations are constrained to not change them willy nilly. In
fact, I consider it imperative that these be Policy; just so
dpkg-divert not suddenly and whimsically change under all the
packages noses.
>> I think the packaging manual can do with some major changes ;-)
Joey> I agree.
Joey> This is only a sampling, I don't have time to re-read all of the packaging
Joey> manual right now.
>>
Joey> 2) There is value in separating technical documentation, which
Joey> can change when the programs it documents change, from
Joey> policy, which can only change after debate on this list.
It is only technical documentation until it attains the weight
of policy. Then the policy is the standard, and the program merely an
implementation.
I do feel the need to document and inveigh the interactions as
policy.
Joey> This second point holds more weight in my mind than the first I
Joey> made. Don't you have any comments on it?
Look at the Emacsen policy. That is based on how a program
works. Look at Flavours. All technical policy documents, at
least initially, are tied to implementations, and evolve with the
implementations.
Then they get an installed base, and the policy
solidifies. Now the implentations follow the standards, rather than
the other way around.
manoj
--
Q: How many IBM types does it take to change a light bulb? A:
Fifteen. One to do it, and fourteen to write document number
GC7500439-0001, Multitasking Incandescent Source System Facility, of
which 10% of the pages state only "This page intentionally left
blank", and 20% of the definitions are of the form "A:..... consists
of sequences of non-blank characters separated by blanks".
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: