Thinking about how to provide an updated cyrus-imapd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Fedora Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Announce]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux