Debian Shibboleth install instructions

[Russ Allbery]

Ferenc Wagner <wferi at niif.hu> writes:

> Hmm, what wiki page?  Your draft is very useful, if only I could have
> read that a week ago!

I want to create a wiki.debian.org page for the pkg-shibboleth team in
general that would point to that page but also include other information
about what we're doing, but haven't had a chance to work on it yet.

> I took the examples from your xml-security-c package.  I don't know if
> you really have to run autoconf before configuring.

Yeah, you'll only need to do this if we're modifying configure relative to
upstream.  git diff upstream..master configure.ac returns nothing for me,
so I think we're not and running Autoconf isn't needed.

>>> #	deleted:    include/xsec/canon/XSECC14n20010315.hpp
>>> #	deleted:    include/xsec/canon/XSECCanon.hpp
>>
>> Are these files shipped by upstream but deleted by make clean?  If so,
>> then this too will force always using --git-ignore-new.
>
> Yes, they are.  However, they aren't removed by make mostlyclean.
> Extracting the tarball, configuring and making mostlyclean results in
> the following:

[...]

Oh, okay, those are a config.h.in equivalent, apparently.  I think we're
going to be stuck with deleting those after the build given the current
upstream build setup.  (I'm not sure why they're modified in place rather
than generated from a template file like config.h usually is, but I'm sure
there's a reason.)

> Can't perhaps pristine-tar pull off a clever trick?

Not for problems like this.  All it can do is pull a tarball back out of a
Git repository in a space-efficient way, but dealing with modifications
like this is beyond its scope.

This is generally a hassle that's always present if you need to delete
files in debian/rules clean.  The only alternative that I know of is to
stash the files and copy the old versions back rather than just deleting
them, which we could do, but which seems like more of a hassle.

> Thanks for the tip.  Does overriding cleaner allow you not to have all
> the build depends installed on the host machine?

Using pbuilder in general allows that, which is very nice.  :)  I usually
don't have the build-dependencies for my packages installed on most of the
systems that I work on.

> This is pretty essential because I need both an Etch and a Sid build
> environment.  Changing them is still tough, I'm tempted to include
> .gbp.conf files into the respective branches... :)

Oh, to get it to use the right branch?  Yeah, that's not a bad idea.  I'm
not sure how to exclude those files from being shipped with the Debian
source package, but I think there's a way.

> On performance, I plan to investigate parallel makes (-j4), which
> could also make a big difference.

Don't build parallel by default; it consumes a lot more memory, which
causes a lot of problems for the Debian buildds for some architectures
like arm and mips.  Instead, you want to honor the parallel=4
DEB_BUILD_OPTIONS setting as documented in the draft Policy proposal at:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=209008#202

which will be in the next version of Debian Policy.

> One more thing: could you please put links to the repositories on the
> Alioth project page?  git.debian.org loads rather slowly, and editing
> the location bar isn't always practical either.

I couldn't figure out quickly how to edit the project home page, so I
added a news entry for the gitweb URLs for the three Shibboleth 1.3
packages.  You should similarly be able to post a news entry (I think you
have all the necessary project rights) for the new Shibboleth 2.0
packages; give that a try and see.

Once the packages have been uploaded, we can just use the QA page for the
package to find all that stuff easily, but it won't update until the
packages have been uploaded of course.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>