Ellie, Дилян, Thanks for the details.
OK, it's clear now that it makes little sense to package cyrus-imapd in different sub-packages from a single build. On the other hand, IMO it makes sense to create different flavors: less functionality normally means less dependencies, smaller size and smaller attack surface. On OpenBSD we have flavors and multi-packages to handle different variants of a package. Multi-packages permit to package different components of a single build in separate sub-packages (PHP is a good example where extra functionality could go into multiple .so without affecting other files). This is the preferred way, if possible, as it builds the same project just once (hence my question). Flavors permit to make multiple builds of the same project with different configure args. There could be some combinations available as pre-compiled binary packages so users can install them directly, and other combinations could be made available in the ports collection (ports = contributed 3rd-party applications ported to work on OpenBSD) where the users can build a package with something like: cd /usr/ports/mail/cyrus-imapd make show=FLAVORS env FLAVOR="http jmap murder ldap clamav" make package and the build infrastructure would build the package with the selected options (if they were defined previously as flavors by the package maintainer) [1]. This way you have some most typical use-cases available pre-compiled for direct install and most other feature combinations available for a simple build in the ports collection. And if your perfect features combination is not available because some feature was not yet separated in a flavor, you're encouraged to send a patch to the port's maintainer defining it, rather than building the project by hand yourself. OpenBSD is different enough from Linux for the most projects not to build without significant adaptations, therefore the ports collection that unifies the efforts. And the ports collection normally has the latest stable versions for all available packages. cyrus-imapd in the ports is at 3.2.4 now [2] (it's a non-flavored/multi-packaged version at the moment, I'm working on making it flavored). Regards, Anatoli [1] https://www.openbsd.org/faq/ports/ports.html [2] https://github.com/openbsd/ports/tree/master/mail/cyrus-imapd On 22/11/20 19:27, ellie timoney wrote: > Hi Anatoli, > > On Mon, 23 Nov 2020, at 4:26 AM, Anatoli wrote: >> do the binaries/libs themselves change or is that new binaries/libs >> appear for each enabled feature? > > Both. > >> In other words, is it possible to make a single build and then package >> everything in 3 package variants (for each configure options group) > > If you've built it with everything included, then there is no particular > advantage to packaging up subsets of that. You might think "we can avoid > bloat by excluding the features we don't need", but in this case all the APIs > to support those features would still be in libcyrus, you would just be > missing binaries. You could have achieved the same effect by just not > running those services in cyrus.conf > >> or should there be 3 different builds? > > This is plausible, but now consider that as a deployment's needs grow and > they need to add features, they will need to reinstall (vs just changing > config). And if you don't have a package that provides the specific set of > features they now need, they either need to build their own Cyrus from source > (negating any benefit of providing packages), or they need to use the "all > the bells and whistles" package anyway (obsoleting the separate packages). > >> >From my experience, there are separate binaries for each feature (like >> >httpd, idled, timsieved, etc.), so it would be possible to prepare >> >different packages by just building it with a complete set of configure >> >args and then including necessary files for each package flavor, but maybe >> >I'm missing something? > > (Discussed above.) > >> I've never packaged cyrus-imapd for others, so no experience here. >> Maybe it also makes sense to add other packaging combinations >> (objectstore, xapian, DBs, ldap, clamav, kerberos)? If there are >> cyrus-imapd package maintainers reading this, could you please share >> your experience? > > I would simply provide one package with all the stable/non-experimental > features enabled, and admins can just not use the features they don't need. > (If deployments need experimental features, they should really be tracking > git master, not using a system package.) > > Cheers, > > ellie ------------------------------------------ Cyrus: Devel Permalink: https://cyrus.topicbox.com/groups/devel/T5acbcb9536dc47c3-M30b3815aef8403c8f98cd443 Delivery options: https://cyrus.topicbox.com/groups/devel/subscription
