On Fri, Jun 11, 2004 at 08:57:52PM +0200, Jeroen van Wolffelaar wrote:
> On Thu, Jun 03, 2004 at 08:57:05AM +0200, Wouter Verhelst wrote:
> > On Fri, May 21, 2004 at 12:56:45PM +0200, Wouter Verhelst wrote:
> > > On Fri, May 21, 2004 at 12:11:42PM +0200, Bill Allombert wrote:
> > > > Also all my packages with non-trivial source process include a file
> > > > ./README.source that explain how source should be handled.
> > >
> > > Hm. That sounds like a good idea, too.
> >
> > Since I got no further replies, let me fix it up to a formal proposal.
> >
> > I propose that the following paragraph be added to the current Debian
> > policy. I'm looking for seconds.
> >
> > (proposal to demand a debian/README.source)
>
> (note: I'm not a DD)
>
> I'm in dubio about this. On the one hand, just demanding a
> debian/README.source still doesn't give a general target for unpacked
> sources.
Indeed; and my first proposal was to require those targets to contain
the same target. However, after thinking about it, and thinking about
Bill's comment quoted above, I came up with the following arguments
against mandating a common name, and for README.source:
* Requiring every package to have the exact same target is quite
intrusive; the different targets in the debian/rules file may depend
on eachother, and while it is theoretically possible to just make a
dummy target which would then list the "real" target in its
dependencies, doing so would be quite ugly.
* I'm not really up-to-date on how these systems work. All packages I've
seen do have a target to unpack the source and one to patch it, but
that doesn't have to mean they all do; so, mandating these targets
might require some maintainers to do a rewrite of their debian/rules
file just so they could be compliant with this rule. That would suck.
For these two reasons, implementing the common name could be quite a bit
of work. Since the idea is to make work easier for other people (as
opposed to making the maintainer's job harder), that's a bug. The same
isn't true for README.source; you can write that in just a few minutes
and be done with it.
* README.source is more flexible. Since its use is, by purpose, not
limited to what's listed in policy, I hope maintainers will have the
common sense to document other "interesting" targets in that file.
By design, this can not happen if we choose to mandate common names
instead of using README.source.
> OTOH, it is a start, and standardizing on a readme file for
> how your source package is arranged might be a good thing. But really
> demanding such a README...
I don't see what's wrong with that. A policy-compliant README.source
could be just a few lines long; it's not as if would be much of a
problem to create one.
> In any case, to prevent insta-buggyness, I propose s/must/should/,
Yes, that had already been suggested, and I accepted that amendment.
> and I would change the last paragraph to really encourage the use, not
> merely allow it:
>
> | Although this file is only required in one specific case (see above),
> | maintainers are encouraged to include a README.source file if the layout
> | of the package is not trivial, so aid understanding of it, even if the
^
as to
> | above condition is not fulfilled.
No objection here. If none of the current seconders (that is, Julian
Gilbey and Bill Allombert) object, I'll accept this.
Bill? Julian?
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
Attachment:
signature.asc
Description: Digital signature