IdP packaging for Linux (deb/rpm)

[Cantor, Scott]

On 5/12/15, 4:39 AM, "Etienne Dysli-Metref" <etienne.dysli-metref at switch.ch> wrote:
>
>If you don't have DEB or RPM packages available,
>automated deployments and upgrades become more painful (i.e. manual,
>can't be repeatedly tested). And tomorrow it's going to be building
>Docker or LXC containers with this...

It's a major concern for this sort of effort that people can't make up their mind, they just keep inventing new ways of doing the same thing over and over and expect everybody to keep up, but it's impossible. Give MS that much credit at least, they've only ever shipped one official installer layer (even if it's nightmarish). One bad system is better then 20 good ones.

If you're just asking about RPM and DEB, that's a more scoped requirement, but I know speaking for myself that I'm not learning Debian packaging. I spent too long figuring out RPM to go repeat all that when there should be plenty of people able to do that work that already know how to do it.

As far as RPMs are concerned, before we do that work, we have to address issues with Jetty as to whether to package that, embed it, deal with setuid (these would have to be arch packages because of that), etc. And we need to let the config situation settle a bit (people are still suggesting large redesigns of all of this stuff) and let the installer itself settle before we start adding packaging.

>So is packaging the IdP (as DEB or RPM) something you [Shibboleth
>developer] could consider doing or have you already decided against it?

I'm not doing DEB (that's a personal statement, not a project decision), but I'm not opposed to the RPM option. I think I am opposed to shipping one that depends on OpenJDK, which means these packages wouldn't actually express their complete dependency set, which may itself be a dealbreaker, I don't know.

But we have limited resources, particularly through next July, and if the membership decides that we need to tackle something huge like OpenID, I can say pretty definitively we're not going to be able to take on much in the way of "smaller" but significant work, not without more people.

Obviously if somebody shows up who wants to do the work, then it's a question of timing and of whether we're comfortable inheriting the work at the end. For RPM at least, I'm probably comfortable taking it over.

The other dimension to this is TIER, if you'll forgive the slight US-centric focus. If TIER can't come up with resources to "just" work on packaging and installation, then a) that means it's a cloud only play and b) it sure as hell isn't going to have resources to work on technical enhancements, and that says a lot.

-- Scott