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

Fixing incorrect .orig

For reasons of confusion and general incompetence I've ended up
uploading a package where the .orig tarball is not actually the
upstream .orig. It's 
a) the .orig plus the set of patches that would normally
   be in debian/patches, and
b) one subdirectory (the important one) of the upstream tarball 
   moved up 4 levels.

b) was because I thought that a dkms package had to be constructed
this way, but it's actualy not true, and I've now worked out how to do
it for an arbitrary layout, so I _can_ just use the upstream tarballs 

a) was because someone else helped with the patches and my git-foo was
weak and I didn't realise they'd got incorporated into the orig.

I have now assembled things properly and worked out how to use
upstream tarballs as-supplied. There is no licencing problem with them
so even though there is some cruft in there it's better to just use
them as they come. This makes updates easier in future and simplifies
traceability. There is also the matter of licence compliance, in
passing on 'the source' (although only useless, unused, bits are
missing, and we do allow repacking, that's not really the point).

Anyway, the question is, what's the best way to fix this?  I can't
upload a new .orig until the upstream part of the version number is
bumped - right?, because any -n debian suffix assumes the same .orig
for the base base version IIRC. Or is there some way to do this?

If I just move everything an upload a -4 to replace -3, I'll get an
800K+ debian diff, removing the whole of the orig source and replacing
it with the same stuff in a different dir, which is silly.

I don't want to upload a new upstream version (yet) because it will
break compatibility with other packages (and in the hypothetical case
of this questions there might well not be one, now, or maybe ever). So
I can either just leave it like it is until it _is_ time to update to
new upstream, at which point this will get fixed, or I can make up
some suitable base version bump and re-upload.

Is there a suffix typically used for this situation of essentially
're-done upstream source' (a bit like we use ds for 'debianised
source' or somesuch when it's been repacked, usually to remove
non-free things or non-source things)?

Or should I just reupload 16.0 as 16.0.0 ? dpkg --compare-versions
tells me that 16.0-3 is less than 16.0.0-1 so that should work. This
seems like the best plan, but I wondered if there was anything

Principal hats:  Linaro, Debian, Wookware, ARM

Attachment: signature.asc
Description: PGP signature

Reply to: