search

apple / ccs-pykerberos

Python Kerberos library used by CalendarServer
https://www.calendarserver.org
Apache License 2.0
117 stars 65 forks source link

Add RPM packaging #25

Closed macosforgebot closed 10 years ago

macosforgebot commented 11 years ago

tylerlhobbs@… originally submitted this as ticket:791

The attached patch makes it easy to build an RPM package by running 'make -f redhat/makefile'.

macosforgebot commented 11 years ago

tylerlhobbs@… originally submitted this as attachment:791-add-rpm-packaging-v1.diff:⁠ticket:791

macosforgebot commented 11 years ago

tylerlhobbs@… originally submitted this as comment:1:⁠ticket:791

Are there any objections to this ticket? I would love for this project to be easily packageable without having to maintain a fork just for this.

macosforgebot commented 11 years ago

@wsanchez originally submitted this as comment:2:⁠ticket:791

There are lots of package systems, and I'm not terribly keen on maintaining a bunch of stuff for those here, and especially if it means adding more directories and files at the top of the project.

macosforgebot commented 11 years ago

tylerlhobbs@… originally submitted this as comment:3:⁠ticket:791

It's true that there are lots of packaging systems, but the deb and rpm package formats are overwhelmingly the most popular, and cover 95% of people that might use this library. Once written, packaging metadata tends to be quite stable and require little ongoing maintenance.

Is there really no way this patch (and the debian packaging patch) will be committed?

macosforgebot commented 11 years ago

@wsanchez originally submitted this as comment:4:⁠ticket:791

Call all of this be put into contrib/?

macosforgebot commented 11 years ago

tylerlhobbs@… originally submitted this as comment:5:⁠ticket:791

Probably so. I would need to make some adjustments to the patches to make that work, but I don't imagine it's too difficult. Would you like me to do that?

macosforgebot commented 11 years ago

@wsanchez originally submitted this as comment:6:⁠ticket:791

Yeah, if we can do, say contrib/dpkg or something like that, I'd be OK with including it.

macosforgebot commented 10 years ago

mcepl@… originally submitted this as comment:7:⁠ticket:791

Replying to tylerlhobbs@…:

It's true that there are lots of packaging systems, but the deb and rpm package formats are overwhelmingly the most popular, and cover 95% of people that might use this library. Once written, packaging metadata tends to be quite stable and require little ongoing maintenance.

Let me comment here as a user (and maintainer of couple of packages) of Fedora (and RHEL). Generally both .spec file and debian/ directory are best NOT to be maintained by the upstream, and also in my (long) experience with RPM packages, various RPM packages are NOT compatible among different RPM-using Linux distributions. All what packages contain is distribution/OS-dependent variables which are different from the upstream (if they are not distro/OS dependent, then they should be of course made part of the upstream code itself).

If you distro doesn’t contain package for pyKerberos (which seems to be the case with the SUSE family, Fedora/RHEL have been having python-kerberos since at least January 2008), then probably the best way is to communicate with the distro maintainer and ask for creating of the package (or package it yourself).

macosforgebot commented 10 years ago

@wsanchez originally submitted this as comment:8:⁠ticket:791

So we've decided that packing data belongs with the packagers, not in our code. Passing on this.