Shibboleth2 packaging

[Russ Allbery]

Ferenc Wagner <wferi at niif.hu> writes:

> I was surprised you asked for the dsc files, but here they are:

Sorry, what I was after was a URL from which I could grab the packages.  I
think you may have sent that already.  If there's a URL for the *.dsc file
and it's in the same directory as the other files, dget can grab them all
at once.

> I'm about to upload the full package files somewhere, but some questions
> arose:
>
>  1. Should we use shibboleth-sp2 as the source package name?

Yes, I think so.

>  2. Should we package opensaml2-schemas or simply provide a newer
>     version of your opensaml-schemas?

Will OpenSAML 2.0 libraries work with the 1.3 Shibboleth SP?  If not,
we're going to have to either conflict or use a different path,
unfortunately.

>  2a. If the first, should that contain /usr/share/xml/opensaml2/* or
>      stay with the current name and conflict with opensaml-schemas?
>      This rules out the optional priority.

As near as I can tell, Shibboleth 1.3 doesn't actually use the schemas.
Does Shibboleth 2.0?  If not, they're sort of extraneous and it probably
doesn't matter very much.

>  3. Similar questions concerning the opensaml source package name.  If
>     both versions are to be present in Debian they probably can't
>     share the name of the source package.

Correct; OpenSAML 2.0 should probably be called opensaml2.

>  4. How will we manage the backports/sid and the 1/2 duality under
>     Git?  Will shibboleth-sp have two branches for version 1 and 2 and
>     four Debian branches for packaging each under Etch and Sid?
>     Or will you create two repositories for the two major versions,
>     and only two Debian branches under each (for Etch and Sid)?

I was planning on creating separate repositories for the 2.0 versions.

>  5. Should we submit ITP's for the above packages and refer to those
>     numbers in the first changelog entry?

Yes.

>  6. Should we separate out the xmltooling-lite library into its own
>     package?

If it's a separate shared library whose SONAME may change independently of
the main library, then yes, it will make life easier later for upgrades.

>  7. What's the preferred way to correctly determine the various
>     (build) dependencies?

I'm not sure what you mean here.

> Sorry to overwhelm you with this bunch of (not too well organised)
> questions, but the 9-hour time zone difference narrows the communication
> opportunities so much...  If you could quicly answer at least some of
> these questions (before I leave to bed) that would be a big bonus: 2
> exchanges instead of 1 per day! :)  Once we get up to speed it won't be
> such an important issue.

I'll give it a shot.  :)

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