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
interface.
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
versions.
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
yours.
>> 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
chatty.
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.
manoj
--
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-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: