[policy] orig.tar.gz unpacking to surprisingly named subdir! (Re: orig.tar.gz)
[ObCrossposts: We should decide what list to discuss this on.]
>>>>> "Henrique" == Henrique M Holschuh <email@example.com> writes:
Henrique> On Sat, 09 Dec 2000, Hamish Moffatt wrote:
>> On Fri, Dec 08, 2000 at 11:33:05PM -0200, Henrique M Holschuh wrote:
>> > Should I be filling a wishlist bug against lintian, or is it ok (although
>> > not optimal) to have .orig.tar.gz files unpacking at foo-1.2.3 instead of
>> > foo-1.2.3.orig ?
>> The tools give warnings, but it really doesn't matter. Quite a lot
Henrique> I didn't receive warnings from any tools (otherwise it wouldn't have taken
Henrique> months for me to notice the problem).
IMO they should be fatal errors, not warnings.
>> of my packages have .orig.tar.gz which unpack into directories
>> with no version number at all, and sometimes even a different name.
>> eg geda-gschem unpacks just as 'gschem/'.
Henrique> I thought that would be the case (many .origs not unpacking to
This is very bad. What if I have (and I do have something like...)
The toplevel dir for all packages built from the "killer-app" source:
The debian/* stuff out of my personal CVS repository:
The source checked out of upstream CVS:
The symlink I use during development builds:
.../killer-app/killer-app/debian -> ../debian.killer-app
... and then when I do a release, it creates the orig.tar.gz
etc. without using the version number for some reason... somebody
else has a similar setup, tracking upstream CVS and my
debian.killer-app/ stuff... and they run an `apt-get source
killer-app' there to get my latest release's debian/* stuff to vendor
track me. It might blow away yet-to-be-submitted patches they have
in the code by untarring to "killer-app".
The version number is important inside .orig.tar.gz for this reason!!
mailto: Karl M. Hegbloom <firstname.lastname@example.org>