[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

 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

	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.

 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: