Bug#250202: mandate a common name for "patched source" and/or "unpacked source"

[Bill Allombert <allomber@math.u-bordeaux.fr>]

On Fri, Jun 11, 2004 at 10:30:58PM +0200, Wouter Verhelst wrote:
> On Fri, Jun 11, 2004 at 08:57:52PM +0200, Jeroen van Wolffelaar wrote:
> > 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.

Each build system tool (dbs,dpatch,cdbs, etc.) should ship such
README.source and let maintainer copy it to debian/. Sometime the
scripts could do it automatically (when converting to the system,
or in debian/rules clean). Of course README.source would contain
very basic instruction and pointer to the build system documentation.

> > In any case, to prevent insta-buggyness, I propose s/must/should/,
> 
> Yes, that had already been suggested, and I accepted that amendment.

I agree, I also accept it.

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

I agree with Jeroen changes.

Basically there are several things you want to do with a source package:
1) Build it umodified. 
   The way to do that is documented and breaking that is most always RC.

2) Modify it and build it.
   README.source should document how to that when the simple procedure
   would fail.

3) Switch to a new upstream version.
   This one is more difficult since we are not responsible for the
   content of new upstream tarball. Nevertheless, I think README.source 
   could document how to proceed in the event of the new upstream
   tarball being nearly identical to the current one, when a special
   procedure is required. (Though we have debian/rules get-orig-source
   already in policy). for example eterm-themes debian/rules
   get-orig-source will grab the themes from the web and build a
   tarball (and check whether they have changed) since upstream does not
   provide such tarball.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here.