Skip to Content.
Sympa Menu

shibboleth-dev - Packaging plans for patch release

Subject: Shibboleth Developers

List archive

Packaging plans for patch release


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: Packaging plans for patch release
  • Date: Mon, 10 Aug 2009 15:57:05 -0400
  • Organization: The Ohio State University

I have a patch release for both branches (2.2.1, 1.3.3) planned for this
week or next and wanted to give a quick heads up as to my plans for
packaging them (other than Windows, which will be handled per usual).

1.3.3 will be prepped with source and RPMs manually by me, same as 1.3.2,
and I don't plan to tackle any packaging issues on that branch, even though
the specfile is a disaster. I don't want to waste the time there.

I plan to move the RPM packaging for 2.2.1 to the OpenSUSE build service as
part of adding support for OpenSUSE officially, and informally for the SLES
commercial releases (informal, because I don't have them and can't actually
reproduce issues there).

The build service is able to produce packages for Red Hat as well, so I hope
to stop producing those by hand going forward.

As part of this move, I've revamped the specfiles quite a bit to support
their conventions, which require special package names for library-only
packages.

For 2.3, I would like to complete the versioning of the library packages for
all platforms, Red Hat included, and get rid of a lot of the conditional
rules in the specfiles, because the SUSE conventions are simply better. But
for this patch, I don't want to risk any disruption, so the package names
the build service will publish for non-SUSE platforms should be essentially
the same as my earlier ones.

I'll get the relevant differences documented in the wiki but since SUSE is
only just now being supported, I'm not in a hurry on that.

This is just FYI to avoid confusion.

One of the other changes is that the key used to sign the 2.2.1 packages
won't be mine. The build service signs them with a key it generates for the
project there. I'll try to get hold of it and put it in the Internet2 hosted
KEYS file, but practically speaking there's no real guarantee there since
that key is controlled by anybody with access to the build service's
back-end servers. If you want origin guarantees beyond that, you can
rpmbuild -ta <tarball> since the source will still be signed by me.

-- Scott




  • Packaging plans for patch release, Scott Cantor, 08/10/2009

Archive powered by MHonArc 2.6.16.

Top of Page