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

Re: Modernizing the upstream tarball without version number change



On Sat, Nov 12, 2016 at 02:12:23PM +0100, Christoph Biedl wrote:
> disclaimer: This is a theoretical situation

pfff :)

> there is an upstream tarball foo_1.0.orig.tar.xz but, quite frankly,
> it's a mess. The creator didn't care about that process and so it
> contains a lot of cruft like a populated .git/, backup files, autotools
> debris, patches applied, you name it. Therefore I'd like to provide a
> clean and much smaller one, ideally one provided by upstream that was
> ignored in the past.
> 
> However, there might be no newer upstream version so I'd have to
> replace foo_1.0.orig.tar.xz with new content, something I consider
> unfriendly[1] and that hopefully[2] gets blocked by technical means.

It is blocked indeed.

> Ideas so far:
> 
> * Fake a new upstream version number, like foo_1.0a.orig.tar.xz.
>   Yes, it's faking. Using "+repack" is more obvious but still means
>   this gets carried into the Debian version number.

+ds is what's usually used.

> * Switch upstream tarball compression. This works, I found an upload[3]
>   where -2 switched from .gz to .xz. Still rather a hack[4], and if this
>   means going away from xz to something older, it feels wrong.

Though it works and indeed it has been used.

> Anything else I could do? It's all a bit first-world-problem-ish and, as
> I said, it's a theoretical question. In the actual cases (outside
> Debian) I could get out of this situation easily since either there was
> a new upstream version, or the source name was a misnomer and needed a
> change anyway. I don't expect to have that luck all the time.

Personally, I'd just repack, appending +ds to the upstream version.
I find switching compression scheme just for the sake of repacking, an
ugly hack; I really really prefer to be shipping whatever upstream
provided me, and if I can't/don't want to do so I want that information
to be clearly visible, in this case in the form of a modified version.

> [1] In my opinion, every file in the Debian repositories that carries a
>     version number should have unique content over all the time. I found
>     some history .dsc files on snapshot.d.o that violate this idea, but
>     I think I should not extend that list.

you really found such things?
'cause really a file once stored in the archive really can't change.
At least, as long as that file is known to dak, it can't change, once a
distribution is archived you theoretically could upload the same
filename with different content.

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Attachment: signature.asc
Description: PGP signature


Reply to: