[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:

 Anthony> On Wed, May 01, 2002 at 06:03:23PM -0500, Manoj Srivastava wrote:
 >> 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. 

 Anthony> So, presumably, this would cover things like update-inetd, the python
 Anthony> policy, perl policy, debconf documentation, and so forth?

	I think so, yes.

 Anthony> How will it do so? By inclusion, or by reference?

	I am open to suggestion, and Julian probably has input on this.

 Anthony> I plan on basically rewriting update-inetd first chance I
 Anthony> get so that it's actually usable for things like xinetd, and
 Anthony> to fix a bunch of bugs that've been outstanding for
 Anthony> years. Part of this will mean completely changing the API
 Anthony> that packages will need to use to talk to update-inetd, and
 Anthony> while there'll be some backwards compatibility, it'll be
 Anthony> mainly intended for upgrades not continued use. How will
 Anthony> this new policy format cope with this?

	I think we need to have a transition plan. Perhaps the new
 update-inetd cold have a different name, if backward compatibility is
 an issue? And we can then try and expedite transition to the new

	I don't see how this is any different from before, though.

 >> Policy, thus, steps in where there are a number of equally
 >> technically viable options,

 Anthony> In update-inetd's case, eg, there aren't a number of equally
 Anthony> technically viable options. There's one -- use the new form
 Anthony> of update-inetd from netbase (or net-common more likely),
 Anthony> and be happy.

	If a number of packages _have_ to use update-inetd, we need to
 nail down an intrerface, and the binary implements the interface. How
 it is implemented is not a policy issue.

	Changes to the interface need to be coordinated, and there is
 no escaping that, anyway

 Anthony> Advice like, say ``4.1. Version numbers based on dates'' or
 >> No, we _should_ standardize on some format for this, 

 Anthony> Huh? We should offer good advice on how to do versioning for
 Anthony> most of the common cases (upstream provides a version?
 Anthony> upstream uses "1.0a, 1.0b, 1.0"?  upstream doesn't provide a
 Anthony> version? upstream uses dates for betas, but some other
 Anthony> scheme for releases?) but that's what "best practices" are.

	That is not what Version numbers based on dates should be about.
 I think it is useful as a guideline for packages build off CVS

 Anthony> Uh, versions just plain aren't a reliable indicator of
 Anthony> anything. We have maintainers to make that judgement call
 Anthony> for us.

	Knowing something is built from CVS is certainly information
 that is significant to me. However, lacking the tools that build on
 top of the version numbering scheme, I would agree it is probably best
 excised from policy, and relegated to the best practices document.

 >> 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. 

 Anthony> That seems like a fairly unsubtle case of policy looking for a reason
 Anthony> to exist.

	That is not a rationale for policy to exist. It was a
 throw away example from the top of my head how there could be utility
 in that information. I am sure people can come up with other such
 uses for a well known format for versions built from the (bleeding
 edge) CVS.

 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> I have no idea what you just said. Would "Notes about
 Anthony> writing descriptions" go in the new policy-standards or
 Anthony> policy-bestpractices? Or which parts would go in which?

	If people argue, as some have, that a fixed, well defined
 ruling on periods and capitalization would aid in presenting package
 selection to the user, then yes, this enhancement would justify
 including it in policy.

	Failing that, I think it is a best practices thing. 

	What goes into policy has never been set in stone. And people
 can always override any individual opinion, including mine, as to
 what belongs where.

 Anthony> What's the principle underlying that choice?

	Does it help in integration? Does it help allowing packages to
 cooperate to make the system as a whole work better? Does it allow us
 to have useful invariants about the distribution as a whole? (like
 following the FHS allows us to say all you need to edit is in /etc --
 or like saying user changes *MUST* be preserved). 

 Anthony> People manage to write conforming C programs without
 Anthony> reference to the ANSI C standard.

	I would like to meet such people. In my experience, very few
 people really code conforming code; and fewer still have the eidetic
 knowledge of the standard to do so from memory.

 Anthony> Should the government step in and outlaw everyone who isn't
 Anthony> versed in the C standard from programming C?

	Is this really conducive to a reasonable discussion?

 Anthony> Reading and understanding the C standard is probably a
 Anthony> sufficient condition for competence in programming C, but
 Anthony> it's not a necessary one.

	I beg to differ. It is, in my opinion, necessary, but not
 sufficient.  I suppose my definition of competence differs from

 >> 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> Policy at the moment provides a fairly thorough grounding in
 Anthony> Debian's best practices. That's highly useful.

	Thorough is a matter of opinion. I think it is inconsistent,
 bumbling mess, occasionally wrong, and bloated, it occasionally
 contradicts itself, related issues are often scattered throughout the
 document, it does not have enough rationale. Its coverage of best
 practices is patchy, and what there is adds to the problem
 determining what is policy and what is the document merely being

 Anthony> Normal standards, like ANSI C and XML and the FHS and the
 Anthony> LSB and whatever else, are usually designed to make
 Anthony> interoperability possible: I can take some ANSI C conformant
 Anthony> code from anyone, and compile and run it on any ANSI C
 Anthony> conformant platform. But there's only one "Debian" platform,

	Wrong analogy. There are nearing 10,000 Debian programs, and
 they are what need to inter-operate. They need to have a set of rules
 they can depend on other packages to be following. That is why each
 Debian package has to be built to this standard.

 Mind precedes its objects. They are mind-governed and mind-made. To
 speak or act with a peaceful mind, is to draw happiness after
 oneself, like an inseparable shadow. 2
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: