Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Thanks for your considerate replies, and continued patience.
So far, when I think I can see the end, it is not the end, and
it gets a little frustrating. :-) So your patience is appreciated.
I've done some testing and experiments, and below are my results.
On Tue, May 29, 2012 at 02:46:32PM +0200, intrigeri wrote:
> Chris Frey wrote (29 May 2012 09:45:15 GMT) :
> > On Tue, May 29, 2012 at 10:48:43AM +0200, intrigeri wrote:
> >> Commit 85a9d87f makes debian/rules stop passing
> >> "DEB_BUILD_MAINT_OPTIONS = hardening=+all" to dpkg-buildflags.
> AFAIK, no large general-purpose distro builds all software with PIE by
> default; this is due to some performance problems on register-starved
> architectures, and the fact it breaks quite some software. So, the
> only practical way for Debian to get more hardening thanks to PIE is
> to have maintainers enable it pro-actively, on a package by package
> basis. Which is what I am kindly asking you to do :)
Don't worry, I've added it back. Just seems "wrong" on a certain level. :-)
I assumed that these default flags could be set on a per-architecture
basis. And if they default to "on", then the packages that legitimately
need things turned off, could disable them. This would leverage the
power of debhelper, buildflags, cdbs, etc.
Making every maintainer update their package in order to support hardening
seems like the long way around. But so be it. :-)
> They are part of what can be uploaded. I also have to build and upload
> the corresponding binary packages.
Interesting... that's a newbie surprise for me. I thought that in the
end, all packages were built with buildd.
> > As for pristine-tar, my initial reaction is that I'm disappointed
> > that I can't get rid of it yet. I had hoped that by taking on the
> > role of maintainer, I could avoid that waste.
>
> What waste, exactly?
The (small) binary xdelta blobs in the source repo. Except for some
graphics, such as background images, buttons, etc., I believe all
the files in the (huge) Barry source tree are text-based source files
that can be read and understood by a human.
In my mind, git is for committing source code, written and reviewed by
a human at each commit, and final binary results are all based on,
and extracted from, that source. Pristine-tar breaks that, by inserting
automated commits in binary format. There is no guarantee either that
the diffs you look at with git-log are the same changes that end up in
the binary file you get out of a pristine-tar commit. It is unlikely
that they will differ, but thinking that pristine-tar is somehow closer
to the real git sources than a signed binary tarball from sourceforge is
mistaken. There is a trust gap in both. The xdelta can contain anything.
Maybe there's an easy way to diff between a git branch and a pristine-tar
tarball, but that's starting to look like hack upon hack to me.
I can certainly understand the convenience of using git for everything,
though. And that might be worth it in itself.
> > If I find a way to make git-buildpackage run for you as expected,
> > without pristine-tar, would that be satisfactory? Maybe that's
> > impossible, but I'd really like to get rid of that dependency.
>
> This would be satisfactory, but indeed it looks impossible to me:
> I don't know how you can ship a source package purely over Git without
> using pristine-tar. If you go on not using pristine-tar, I still have
> to fetch both from Git and (at least) the orig.tar.gz from a painful
> web site.
>
> pristine-tar was created *exactly* to allow shipping, over Git, the
> tiny delta that goes between a Git tree and a .orig.tar.gz.
The debian/rules script contains the code needed to run autoreconf,
so it is possible to simply checkout a tag and build Debian packages
straight from there.
It is also possible to extract consistent tarballs using git-archive,
and do the same thing. Pristine-tar uses git-archive for the bulk
of its work as well.
If I stop autogenerating configure in the .orig.tar.gz, and stop
pre-generating html docs in it, which aren't used anyway, it should
be possible for you to import the .dsc file using git-buildpackage
and have a completely empty git-diff between my release tag
and your git-buildpackage master tree. This would allow you to peruse
my upstream git log with certainty that you're actually viewing the real
changes.
I don't think you'll need to use debdiff anymore.
To test this, I did:
git init
git remote add barrypublic git://repo.or.cz/barry.git
git fetch barrypublic
git-import-dsc --pristine-tar --download http://sourceforge.net/projects/barry/files/barry/barry-0.18.2/sources/barry_0.18.2-1.dsc
git-import-dsc --pristine-tar --download http://sourceforge.net/projects/barry/files/barry/barry-0.18.3/sources/barry_0.18.3-1.dsc
git diff --stat master barry-0.18.3
I hacked dget to accept unsigned .dsc files for my test. I'll have to
start signing those to make this easier.
But the diff between the master branch (created by git-buildpackage) and my
barry-0.18.3 tag only contained the autogenerated files for the html docs
and autoconf. Without such cruft in the .orig.tar.gz release, you could
easily import my releases, and review them at will, and use git-buildpackage
however you like. It would make the release files smaller too.
The downloads from sourceforge worked just fine from the command line.
This also solves the upstream debian/ directory issue. Since you're
importing my .dsc packages, the splitting of debian/ into debian.tar.gz
is done on my side. And upon importing things via git-import-dsc,
git-buildpackage does it for you as well, giving you a pristine upstream
branch to work with, and a master that matches my release.
> However, barry is clearly no native package, and e.g. you may have to
> branch e.g. a wheezy branch out of an old state of you master branch
> at some point, e.g. to prepare a stable or security update, or
> a backport.
Presumably, the Wheezy package would remain fairly frozen in time,
say at version 0.18.X-Y. This would be found in the Barry repo under
the tag: barry-0.18.X-Y. To fix something, I'd create a branch
on that tag, fix, release, and tag it as barry-0.18.X-Z.
Any important fixes from master can be git-cherry-picked into the
new branch, or added as source package patches.
> But well, this being said, just take my mere advice for what it is,
> make your own decision, and deal with the consequences -- perhaps
> barry won't ever need a stable or security update, and perhaps things
> won't get as complex as I am implying :)
Thank you. :-) I would like to try it with an upstream debian/, and see
if I can keep only one version of it. This is why I prefer things like
CDBS and sticking to defaults where possible. I've found that having
more than one copy of a file becomes it's own unique nightmare.
Of course, this one version of debian/ will be tagged at every release
ever made, and these tags can become branches at a moment's notice to
fix whatever version needs an update at that time.
> > If worse comes to worst, would it be possible to get a git repo
> > somewhere on debian.org that I could push pristine-tar stuff to?
>
> Sure. We could easily get a Git repository in collab-maint on Alioth.
This is a good backup plan. Thank you for this.
Please let me know what you think of my above plan. If it is satisfactory,
I can release barry-0.18.3-2 soon, and we can see how our workflows mesh.
- Chris
Reply to: