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

Re: Popularity of bzr-builddeb and dh-make

On Thu, Oct 18, 2012 at 22:29:53 -0700, Steve Langasek wrote:

> On Thu, Oct 18, 2012 at 09:54:27PM -0700, Russ Allbery wrote:
> > > AIUI, most users of pristine-tar in git don't have the second of these
> > > branches, which means the pristine-tar binary delta is done against the
> > > upstream branch - so each pristine-tar blob contains all the information
> > > about autogenerated files in the tarball, in a format that doesn't in
> > > turn compress well in the git repository.
> > Oh.  No, I'm fairly certain that you're wrong, since any user of
> > git-buildpackge will have the second.  Rather, what's normally missing
> > from most Git-based packaging is the *first* branch, since the
> > git-buildpackage workflow was designed originally around importing
> > upstream tarballs to create the second branch.
> Ok.  Well, bear in mind that this is all second-hand.  I was complaining on
> IRC about having to work with the designated Vcs-Git branch on a package (I
> don't remember which) that didn't use pristine-tar, and multiple developers
> rallied to the defense of this practice, claiming that pristine-tar caused
> git repositories to rapidly balloon in size.  Perhaps one of them can speak
> for themselves about what they think the issues are. :)
That might well have been me.  I don't know what "most Git-based
packaging" does, as I don't have much git-based packaging experience
outside the XSF...

I've tried importing the xorg-server tarballs using pristine-tar against
the upstream git release tags once, and it made the repo unbearably
large (each delta was huge, and git couldn't compress it meaning the
repo size increased linearly with the number of imported tarballs).

Note that I don't use git-buildpackage (I tried it a couple of times a
while ago, it didn't seem to add anything I cared about to
dpkg-buildpackage, other than complexity), and I don't store or want to
store the autotools noise in the packaging or upstream branches, so in
order to import the tarballs properly I'd have to add a new branch (or a
bunch of tags) for their contents and remember to update and push it
along with the other branches at each upstream release.  And if I ever
forgot to push one of those that'd make the pristine-tar branch useless
for anyone else, since they wouldn't have the needed data.  Easier to
just use uscan to get the tarball from upstream, so bothering with
pristine-tar didn't seem worth it at the time.


Attachment: signature.asc
Description: Digital signature

Reply to: