Re: [Mageia-dev] [changelog] [RPM] cauldron core/release dovecot-1.2.17-3.mga2
Le 27/02/2012 08:00, Maarten Vanraes a écrit : Is it necessary to have these --with[out]* compile flags in the package description? maybe not necessary, but definitively useful. maybe it'd be better to just list whatever support it has been built with. It has been a standard practice for all our packages allowing conditional build options for quite a long time. Of course, this could be mentioned elsewhere as package description. -- To spot the expert, pick the one who charges the most money. -- Murphy's Theory Concerning Antique Dealers
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release dovecot-1.2.17-3.mga2
Op maandag 27 februari 2012 09:20:17 schreef Guillaume Rousse: Le 27/02/2012 08:00, Maarten Vanraes a écrit : Is it necessary to have these --with[out]* compile flags in the package description? maybe not necessary, but definitively useful. maybe it'd be better to just list whatever support it has been built with. It has been a standard practice for all our packages allowing conditional build options for quite a long time. Of course, this could be mentioned elsewhere as package description. i have no problem it being in the spec file, but surely a better place rather than the description... it's not like users really need to know which compile flags there is or what you can do with rpmbuild... i'm just saying this info should be moved out to comments in spec file, and change the description to state what exactly is compiled in...
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release dovecot-1.2.17-3.mga2
Maarten Vanraes a écrit : Op maandag 27 februari 2012 09:20:17 schreef Guillaume Rousse: Le 27/02/2012 08:00, Maarten Vanraes a écrit : Is it necessary to have these --with[out]* compile flags in the package description? maybe not necessary, but definitively useful. maybe it'd be better to just list whatever support it has been built with. It has been a standard practice for all our packages allowing conditional build options for quite a long time. Of course, this could be mentioned elsewhere as package description. i have no problem it being in the spec file, but surely a better place rather than the description... it's not like users really need to know which compile flags there is or what you can do with rpmbuild... i'm just saying this info should be moved out to comments in spec file, and change the description to state what exactly is compiled in... It can be very useful for users to know what functions are activated in a package - which the compile flags often indicate. In the man page (or other documentation) there is often reference to functions available if activated. So I would favour keeping compile flags in the description, if it is possible that they make a difference in the functions available. However if the compile flags are required to make the package build properly, then it does make sense to make them a comment in the spec file. My 2 cents :) -- André
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release dovecot-1.2.17-3.mga2
Is it necessary to have these --with[out]* compile flags in the package description? maybe it'd be better to just list whatever support it has been built with. Op zondag 26 februari 2012 19:46:34 schreef colin: Name: dovecot Relocations: (not relocatable) [...] Description : Dovecot is an IMAP and POP3 server for Linux/UNIX-like systems, written with security primarily in mind. Although it's written with C, it uses several coding techniques to avoid most of the common pitfalls. Dovecot can work with standard mbox and maildir formats and it's fully compatible with UW-IMAP and Courier IMAP servers as well as mail clients accessing the mailboxes directly. You can build dovecot with some conditional build swithes; (ie. use with rpm --rebuild): --with[out] gssapiGSSAPI support (enabled) --with[out] ldap LDAP support (enabled) --with[out] luceneLucene support (enabled) --with[out] mysql MySQL support (enabled) --with[out] pgsql PostgreSQL support (enabled) --with[out] sqliteSQLite support (enabled) --with[out] sieve CMU Sieve support (enabled) --with[out] managesieve MmanageSieve support (enabled) [...]