Re: Working on debian developer's reference and "best packaging practices"
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.
So, presumably, this would cover things like update-inetd, the python
policy, perl policy, debconf documentation, and so forth?
How will it do so? By inclusion, or by reference? I plan on basically
rewriting update-inetd first chance I get so that it's actually usable for
things like xinetd, and to fix a bunch of bugs that've been outstanding
for years. Part of this will mean completely changing the API that
packages will need to use to talk to update-inetd, and while there'll
be some backwards compatibility, it'll be mainly intended for upgrades
not continued use. How will this new policy format cope with this?
> Policy, thus, steps in where there are a number of equally
> technically viable options,
In update-inetd's case, eg, there aren't a number of equally technically
viable options. There's one -- use the new form of update-inetd from
netbase (or net-common more likely), and be happy.
> 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.
Well, the format of control files, and what goes into debian/rules,
and what environment variables dpkg-buildpackage will set, all seem
likely contenders for "standardisation", but not in a way that seems
useful to anyone. But apparently this isn't what you were talking about,
so that's probably good.
> Anthony> Advice like, say ``4.1. Version numbers based on dates'' or
> No, we _should_ standardize on some format for this,
Huh? We should offer good advice on how to do versioning for most of the
common cases (upstream provides a version? upstream uses "1.0a, 1.0b,
1.0"? upstream doesn't provide a version? upstream uses dates for betas,
but some other scheme for releases?) but that's what "best practices" are.
Forbidding anyone from doing anything else is unnecessary and silly.
> and this
> may be used by tools to flag bleeding edge packages just from the
> vbersion format.
Uh, versions just plain aren't a reliable indicator of anything. We have
maintainers to make that judgement call for us.
> 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.
That seems like a fairly unsubtle case of policy looking for a reason
to exist.
> 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.
I have no idea what you just said. Would "Notes about writing
descriptions" go in the new policy-standards or policy-bestpractices? Or
which parts would go in which?
What's the principle underlying that choice?
> 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?
People manage to write conforming C programs without reference to the
ANSI C standard. Should the government step in and outlaw everyone who
isn't versed in the C standard from programming C?
Reading and understanding the C standard is probably a sufficient
condition for competence in programming C, but it's not a necessary one.
It's still not clear to me what exactly you want this new "Debian
standard" to be, so it's not clear if it'll actually be like the C
standard in that manner, or if not, exactly what it'll be like. Well,
to me, anyway.
> 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.
Well, either we have well defined rules now, in which case that isn't
an argument for change, or we don't and it doesn't spell disaster for
us after all.
> 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.
> Secondly, a standards document does not mean legalese.
Really? It's not going to be written in such a way that there aren't
whole bunches of unstated exceptions? That seems very difficult to maintain.
> 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?
Policy at the moment provides a fairly thorough grounding in Debian's
best practices. That's highly useful.
Normal standards, like ANSI C and XML and the FHS and the LSB and
whatever else, are usually designed to make interoperability possible:
I can take some ANSI C conformant code from anyone, and compile and
run it on any ANSI C conformant platform. But there's only one "Debian"
platform, and it changes each year (or so). So there's no independent
implementations of Debian to be interoperable with, so I don't see the
point of a "Debian standard".
I'm probably just not grokking what you mean, though.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``BAM! Science triumphs again!''
-- http://www.angryflower.com/vegeta.gif
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: