I've been doing a lot of packaging work on the Fedora version of the
cyrus-imapd package, including a lot of work with upstream to do things
like run their external test suite as part of the package build process,
and fix issues that only show up on 32-bit or big-endian architectures.
One thing they asked me is whether it would be possible to provide
packages for their current version to EPEL7, since the version in RHEL7
is extremely old and lacks a significant amount of functionality. So
I've been looking into it and wanted to see if I could create a package
which would be even remotely acceptable under EPEL rules.
Obviously the package couldn't be named "cyrus-imapd", so I'd use
"cyrus-imapd3" instead.
Obviously I would have to avoid conflicts with the base EL7 package.
* Internal daemons and such would just go to a different directory.
* User-facing executables would have to be renamed or placed somewhere
outside of the PATH. Or both: placed outside of PATH with original
names, and with non-conflicting symlinks in PATH.
* Manpages would need to be renamed to be in a separate section.
The package would need the PAM configuration be in place. Unfortunately
these are just generically named files in /etc/pam.d: csync, imap, lmtp,
mupdate, nntp, pop, sieve. In both RHEL and Fedora, these are provided
both by the cyrus-imapd and uw-imap packages. They don't conflict
because the files are identical between these packages.
Is it acceptable for a package to do the same thing? Can my
hypothetical cyrus-imapd3 package provide the same files as the base
RHEL cyrus-imapd and uw-imap packages? There would be no conflict
because the files would be the same.
I could also just leave them out and leave it to manual configuration, I
guess, but that seems suboptimal.
Some dependencies in EL7 are pretty old, but that can be worked around:
* libical is in base RHEL7 and is quite old. I would need to either
bundle or separately package libical 2.
jansson might barely be new enough, but if not then I'd be bundling
or separately packaging lansson2.10.
xapian-core is in EPEL, but the version is too old. I can ask the
EPEL maintainers about an update but I would probably need to bundle
or separately package this as well.
So this seems like a lot of work. If I didn't care about conflicts I
could just toss up a COPR and let upstream pretend it's official. But
being in EPEL has benefits, I guess. If anyone is interested in working
on this, or just has any ideas about how I can do this without running
afoul of EPEL's packaging rules, please let me know.
- J<
_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
