Re: Working on debian developer's reference and "best packaging practices"
>>"Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:
>> On Tue, Apr 30, 2002 at 03:46:17PM -0500, Manoj Srivastava wrote:
>> > Apropos to that, Policy proper contains elements that ought
>> > not to be in there, but remain as vestigial documentation of dpkg
>> > (which is how policy started). Policy is going to be cleaned up and,
>> > and perhaps rewritten (probably in DocBook format) post woody (I like
>> > the layout of the sections in the FHS 2.2 document); and made into a
>> > more coherent, leaner version, as befits a standard document. Some of
>> > the examples need to be pruned from the policy proper; so a look into
>> > policy would be appreciated.
Anthony> What exactly is the.. raison d'etre of this new policy to be,
Anthony> then?
What exactly is it that we do in Debian? For the most part, we
do not generate code, except for glue -- we are integrators. We make
the system work together. The value added by Debian is the assurance
that someone has tried to make things work together, figured out
dependencies, and ensure that different package do not trample over
each others toes, and packages can work together.
Even more than just not break other packages, we allow
synergies to develop between packages, and policy is essential for
this: packages follow policy, and can expect, and depend on, other
packages to also be policy conforming. Knowledge of this behaviour
allows for enhanced cooperation between packages.
Debian policy should be the minimalistic set of rules that
packages follow, and expect other packages to foolow too, in order to
have the system be greater than the sum of the parts. This is what
allows packages to dump HTML file in a location on the file system
and expect it to show up on the web server. This is what allows us to
have a menu system, automated completions in bash, auto-recompilation
of elisp packages, and a plethora of other synergies that elevates
Debian above all other Linux (_NOT_ just GNU/Linux) distributions.
Policy, thus, steps in where there are a number of equally
technically viable options, and one needs be chosen to assure
compatibility, or to achieve a degree of consistency required for
management or other front-end tools. Location of configuration files,
the web root, games, etc, are (mostly?) covered by other standards
(like the FHS and LSB), and ratified by policy, with exceptions to
the standards noted (/usr/doc/package syml;inks at the time of
releasing woody is an example). Yes, sometimes Debian is different
form the standards, and often we have a good reason for doing so.
With the growing number of maintainers, and packages, it is
essential that the rules that package must adhere to in order for the
system to function seamlessly be accessible, obvious, and not drowned
in style guide pontifications.
The packaging system is a coner stone of the distribution,
Policy encodes the "standard" interfaces to this system that the
packaging system _must_ provide -- the packaging system may offer
added facilities, and an expanded, backwards compatible interface,
compared to what is documented in policy. However, policy is still no
substitute for reading the actual documentation involved.
(Wichert: under this definition, inclusion of enhances: in polcy was
wrong)
Anthony> Personally, I can't see the need for a "standards" document
Anthony> for Debian -- yes, POSIX, the FHS etc are useful, but
Anthony> they're already standards; and documentation on how to use
Anthony> dpkg and debhelper and debconf etc is needed, but that tends
Anthony> to change much more regularly than, say, ANSI C or POSIX
Anthony> does, so doesn't really seem all that appropriate for a
Anthony> "standards" process.
Policy is not dpkg documentation. Indeed, dpkg authors have
started writing the canonical documentation on how to use the
packaging tools, and there is no need to make that policy, anymore
than gcc.info needs be policy.
>> > My vision of policy is like that it is analogous to, say, the
>> > C standard, and not a DPKG for dummies or teach yourself packaging in 24
>> > hours kind of document. It would be nice if the "Debian Best
>> > Packaging Practices" document plays a complementary role and picks up
>> > the slack. It would perhaps make policy more digestible.
Anthony> Advice like, say ``4.1. Version numbers based on dates'' or
No, we _should_ standardize on some format for this, and this
may be used by tools to flag bleeding edge packages just from the
vbersion format. Perhaps we cna then institute a practice that date
based version nubm,ers mean that packges do not automatically advance
to testing, but require a signed message from the maintainer to some
location in Debian to have the package advance.
Consistency is not merely for consistencies sake. Consistency
also allows for automated tools to take advantage the fact that
packages in Debian conform to policy.
Anthony> ``5.7.1. Notes about writing descriptions'' or
Apart from the minimal parsing requirement, and an assurance
that a certain description format shall be correctly parsed by the
packaging tools, the only rationale for includingt this in policy is
to allow use fron ends to present the information in a pleasing,
configurable fashion to the end user.
Due to the burgeoning number of packages in Debian, package
selection, and management, is perhaps the most daunting task facing
users, and the situation is unlikely to ameliorate.
Any help we can offer the front end tools by enforcing some
consistency in the descriptions is likely to help.
Anthony> ``12.4. Editors and pagers'' are good advice on how to make
Anthony> sure what your packaging is high quality, but much of it
Anthony> doesn't seem incredibly appropriate for something written to
Anthony> be like the "C standard".
It was an analogy. Editors and pagers policy ensre that users
can maintain their usual preferences, while allowing programs to
invoke the editor or pageer of the _users_ choice. This functionality
is central to what we do in Debian: we make the system an efficient,
cooperating, working whole, where things come into play together, as
seamlessly as we can make it do so.
Anthony> For that matter, "style guides" tends to be a lot more
Anthony> useful than "standards", and referred to by a greater
Anthony> proportion of the people trying to write in, eg, C. If
I almost never refer to style guides any more. I constantly
refer to the standards themselves. Style guides were useful for a
very short interval when I was a novice; since then, I probably have
spent more time writing internal style guides than I have reading
them
And it is not as if we are not going to have style guides:
what else do you think Raphael is proposing?
Anthony> "policy" is only going to be referred to be a small
Anthony> proportion of developers, is it really worth maintaining?
Policy is required to be followed by packages in order to have
the system function as a whole. People not interested in that should
perhaps think or pursuing other hobbies?
Anthony> To sum up: there're two things that bother me about
Anthony> this. One is that I don't really see the point of a "Debian
Anthony> standards" document.
I can't help you there. I do know that a lack of well defined
rules spells disaster for any integration effort.
Anthony> It might be fun to be chair of a standards committee, but I
Anthony> don't see how the content of it is going to actually benefit
Anthony> anyone.
I rartely do things for the pleasure of the exercise of
power. Indeed, I have tried to set up the policy groiup with as
little centralized control of power, even though some DPL's have
offered me the role of policy czar.
Secondly, a standards document does not mean legalese.
Thirdly, if you do not understand the value of standards (I do
not think this is the case, but you did actually say that), then
there is no point in policy at all, is there?
Anthony> The more important thing that worries me though is that this
Anthony> might be done in a way similar to how the packaging manual
Anthony> was "merged", trimming out a whole bunch of useful
Anthony> information on the assumption that it'll get rewritten into
Anthony> a new document, that never eventuates.
Take that up with the dpkg maintainers. We have included the
packaging manual as an informative appendix when it became clear that
the new document was taking more time than was initially anticipated.
Anthony> Losing all the non-prescriptive information from
Anthony> debian-policy would be rather horrific.
Indeed, I see the new policy document to have more
non-normative information, in the form of rationale and examples, but
presented in a fashion that it could be elided as desired.
Anthony> Considering the packaging manual doesn't exist anymore, I
Anthony> don't see how anyone could make that complaint.
Refer to Appendices B, C,D,E, F,and G of the policy.
manoj
--
When I woke up this morning, my girlfriend asked if I had slept
well. I said, "No, I made a few mistakes." Steven Wright
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-project-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: