[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Removing parts of upstream tar-ball, parsers, autobuilding



Hi,

IANADD, but anyways some comments:

On Thu, Dec 13, 2007 at 07:03:54PM +0530, Y Giridhar Appaji Nag wrote:
> 1. I have an upstream source tar-ball that accidentally includes some
> files that are generated (and cleaned when a make distclean is issued)

the question to decide is: What files does the tarball include so that
you *must* remove them? AFAICS it seems to be general consensous that
changes to the upstream source tarball must not be done if there is no
good reason. I won't consider "they don't need to be here" a good
reason.

> Now, the best thing to do would be to copy the upstream tar-ball as-is
> to orig.tar.gz and have a patch that removes these files (this will
> result in a big diff).  However, is it OK to create an orig.tar.gz file

Why do you need to remove them? Are they causing any impact? If not: Why
not leave them alone?

> based on the upstream tar-ball with these files removed?  Do maintainers
> create a new orig.tar.gz based on the upstream tar-ball and use it (even
> in the non pkg-modified-to-be-dfsg case)?

There are rare cases where repackaging seems appropriate, e.g. for
removing an upstream provided debian directory, or in the (you named it)
case where upstream sources contains non-dfsg material.

> 2. Are there packages in our archive that directly include parsers
> (generated by bison etc.) in the orig.tar.gz directly rather than
> "Build-Depends"-ing on the parser-generator?

Hm. I don't know, but I would consider this quiet crappy.

> I am guessing that there shouldn't be any (unless the parser is
> hand-edited heavily later) because a bug in the generated parser because
> of the parser-generator would be difficult to spot.

But this case is one of the worst I could imagine. If it is hand-edited
later it would be impossible for someone else to recreate the parser
later. Better would be to patch the input files to create a parser as it
is needed.

Regards,
Patrick



Reply to: