postfix-2.9.0 has a broken out-of-the-box daemon_directory set to: daemon_directory = /usr/libexec/postfix In 2.8.x ebuilds, this was fixed at compile time using this: mycc="${mycc} -DDEF_DAEMON_DIR=\\\"/usr/$(get_libdir)/postfix\\\"" But this has been removed from 2.9.0 ebuild. I know this can be workarounded by specifying "daemon_directory = /usr/lib/postfix" inside main.cf. But it should be nice to restore the previous behaviour having a correct default ! # emerge --info postfix Portage 2.2.0_alpha84 (default/linux/amd64/10.0/desktop, gcc-4.5.3, glibc-2.14.1-r2, 3.2.1-gentoo-r2 x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.2.1-gentoo-r2-x86_64-Intel-R-_Core-TM-2_Quad_CPU_Q9300_@_2.50GHz-with-gentoo-2.1 Timestamp of tree: Thu, 02 Feb 2012 10:30:01 +0000 app-shells/bash: 4.2_p20 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.2-r3, 3.2.2 dev-util/cmake: 2.8.7-r2 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.1 sys-apps/openrc: 0.9.8.4 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.9.6-r3, 1.11.2-r1 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.5.3-r2 sys-devel/gcc-config: 1.5-r2 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 3.2 (virtual/os-headers) sys-libs/glibc: 2.14.1-r2 Repositories: gentoo gcpan_overlay xwing local Installed sets: @system ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -mtune=native -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/openvpn/easy-rsa /usr/share/themes/oxygen-gtk/gtk-2.0" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=native -O2 -mtune=native -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps y" FEATURES="assume-digests binpkg-logs buildsyspkg collision-protect distlocks ebuild-locks fixlafiles metadata-transfer news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unm erge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="" GENTOO_MIRRORS="ftp://ftp.free.fr/mirrors/ftp.gentoo.org/ ftp://mirror.switch.ch/mirror/gentoo/ http://trumpetti.atm.tut.fi/gentoo/ http://mirror.ovh.net/gentoo-distfiles/ http://gentoo.tiscali.nl/" LANG="fr_FR.UTF-8" LC_ALL="fr_FR.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,--sort-common" LINGUAS="fr" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/gcpan-portage /usr/local/portage/portage /usr/local/portage/local-portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi additions alsa amd64 bash-completion branding bzip2 cairo cdda cdr cli clucene consolekit cracklib crypt cups cxx dbus dri dts dvb dvd dvdnav dvdr emboss encode exif extensions firefox flac fontconfig for tran fr gdu gif gpm gtk iconv idn iproute2 ipv6 ithreads jpeg kde lcms libnotify live llvm lzma mad matroska minizip mmx mng modules mozilla mp3 mp4 mpeg mudflap multilib ncurses network nls nptl nptlonly nsplugin ofx ogg opengl openmp openssl pam pango pcre pdf png policykit pppd qt3support qt4 rdesktop rdp readline sasl scanner semantic-desktop session spell sse sse2 ssl startup-notification svg sysfs syslog tcpd theora threads tiff truetype udev uni code usb v4l v4l2 vaapi vim-pager vim-syntax vnc vorbis x264 xattr xcb xcomposite xml xorg xulrunner xv xvid xvmc zip zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hook s iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic nego tiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="fr" NGINX_MODULES_HTTP="access auth_basic autoindex browser charset empty_gif fastcgi gzip he aders_more limit_req limit_zone map proxy realip referer rewrite stub_status upstream_ip_hash userid" PHP_TARGETS="php5-4" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nouveau" XTABLES_ADDONS="quota2 psd pknock lscan length 2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS ================================================================= Package Settings ================================================================= mail-mta/postfix-2.9.0 was built with the following: USE="(multilib) pam sasl ssl -berkdb -cdb -doc -dovecot-sasl -hardened -ldap -ldap-bind -mbox -memcached -mysql -nis -postgres (-selinux) -sqlite -vda" CFLAGS="-march=native -O2 -mtune=native -pipe -Wno-comment" CXXFLAGS="-march=native -O2 -mtune=native -pipe -Wno-comment"
We still install to /usr/$(get_libdir)/postfix directory and this setting is recorded in the installed main.cf. We just don't change the postfix default anymore but I fail to see why that is a problem.
(In reply to comment #1) > We just don't change the postfix default anymore but I fail to see why that is > a problem. It's a problem because default config cannot run (before it could), and you have now to hard-code in you configuration file the daemon_directory path. I agree, this is not a *big* problem, but imho it's annoying enough, breaking configs that used to run perfectly with the previous ebuild (2.8.7, that's why I noticed it), and easy to fix by adding only one line in the ebuild. So... But now, it's up to you !
(In reply to comment #2) > I agree, this is not a *big* problem, but imho it's annoying enough, breaking > configs I will fix it if it breaks backward compatibility but I fail to see how it does that. Daemons still get installed in /usr/$(get_libdir)/postfix and this is recorded in main.cf, i.e. you don't have to adjust your main.cf manually. You still have to run dispatch-conf/etc-upgrade tho. Please clarify how and what got broken when you upgraded to 2.9.0.
So yes, daemon is correctly installed in /usr/$(get_libdir)/postfix, no problem with that. And yes, I saw the etc-update. But when you are managing your configuration in a centralized way, and deploying it to the different servers from this unique point, it's convenient to avoid having hard-coded path all around (until today, I had absolutely no hard-coded path in my postfix configs): it make the sharing of configuration between heterogeneous platforms easier and reduces the configuration maintenance burden. Default are imho here for that : you can rely on a sane working default so you do not need to hard-code and override anything in your config, and you can skip such basic parameters. For me, broken default that need to always be overridden to work is bad and looks like some QA regression. Ok, it's from my sysadmin point of view :) Just to be sure to be correctly understood: here the problem I speak about is not about etc-updating or not the configuration and main.cf content. It's about the "postconf -d" default (the one that is not changed by the installed main.cf) that imho should be correct and working without overriding it. That was the case before 2.9.0. Thanks for reading me :)
Changing postfix defaults has its drawbacks. When upstream changes the default, it will come back and bite us. If not me, then the next maintainer. Using cfengine/puppet/whatever might be a good choice if you are managing lots of systems. Closing.
Sorry but is horribly incoherent : YOU change the default installation at line 191 in the ebuild, not postfix team: 183 /bin/sh postfix-install \ 184 -non-interactive \ 185 install_root="${D}" \ 186 config_directory="/etc/postfix" \ 187 manpage_directory="/usr/share/man" \ 188 readme_directory="/usr/share/doc/${PF}/readme" \ 189 html_directory="/usr/share/doc/${PF}/html" \ 190 command_directory="/usr/sbin" \ =================================== 191 daemon_directory="/usr/$(get_libdir)/postfix" \ =================================== 192 mailq_path="/usr/bin/mailq" \ 193 newaliases_path="/usr/bin/newaliases" \ 194 sendmail_path="/usr/sbin/sendmail" \ 195 || die "postfix-install failed" If you want just to be coherent you have to change the default installation with the "mycc="${mycc} -DDEF_DAEMON_DIR=\\\"/usr/$(get_libdir)/postfix\\\""" just like it's done in the 2.8.* ebuild... It will not "come back and bite us" when upstream changes default, since YOU already changes the default. But only partially, thus breaking the (internal) default configuration set. It's a matter of coherence. (And yes, this coherence you broke helps me) Either change both, or change none !! This is *ONE* line to add in the ebuild to keep coherency, and this line was here before, in the 2.8.* ebuilds. Why the hell removing it ??? Just for the story: postfix by default installs to libexec and daemon_directory is set by (internal not configuration) default to libexec. This is coherent. YOU installs to $(get_libdir) and set (internal not configuration) default to libexec You still do not see something wrong here ?
There are two defaults. By default, we are installing to /usr/$(get_libdir)/postfix/ and this is fine. Then there is the compile time default and we will keep it the same as upstream. Do not reopen the bug with the same argument. It is not good enough.
Two default which are not coherent and that were in postfix-2.8.* ebuilds, and in my opinion have to be ! Keeping a compilation default different than gentoo install default (which is get_libdir instead of libexec by policy) is just insane. Both are the same in postfix distribution, both should remain the same after the install directory change needed by gentoo policy... For me it sounds like a QA regression (please, forget the personal case that made me notice it, just focus on defaults coherency !). So I think we need an external point of view, so I will CC QA team. I know you are the one who maintains the package and I thank you for that, but you are not god. I noticed that you want me to justify me with lots of details, but you, you justify nothing. So tell me, why do you want to change the ebuild behavior and introduce weird incoherent defaults, although they were fine before ? Just because you want to remove some simple lines in an ebuild ? Sorry, it's not enough. Where is the gentoo policy that says: "don't touch the upstream defaults, just change the installation path to match our policy, and no matter if that make the default configuration not coherent and broken" ? Sorry, I do not see the point here, so please tell me ! And just to be clear, here is the patch against the 2.9.0 ebuild that make the defaults coherent again we speak about (taken from 2.8.8 ebuild): --- postfix-2.9.0.ebuild.old 2012-02-04 08:53:18.546015541 +0100 +++ postfix-2.9.0.ebuild 2012-02-04 08:54:10.992016888 +0100 @@ -163,6 +163,20 @@ mylibs="${mylibs} ${CDB_LIBS}" fi + mycc="${mycc} -DDEF_DAEMON_DIR=\\\"/usr/$(get_libdir)/postfix\\\"" + mycc="${mycc} -DDEF_CONFIG_DIR=\\\"/etc/postfix\\\"" + mycc="${mycc} -DDEF_COMMAND_DIR=\\\"/usr/sbin\\\"" + mycc="${mycc} -DDEF_SENDMAIL_PATH=\\\"/usr/sbin/sendmail\\\"" + mycc="${mycc} -DDEF_NEWALIS_PATH=\\\"/usr/bin/newaliases\\\"" + mycc="${mycc} -DDEF_MAILQ_PATH=\\\"/usr/bin/mailq\\\"" + mycc="${mycc} -DDEF_MANPAGE_DIR=\\\"/usr/share/man\\\"" + mycc="${mycc} -DDEF_README_DIR=\\\"/usr/share/doc/${PF}/readme\\\"" + mycc="${mycc} -DDEF_HTML_DIR=\\\"/usr/share/doc/${PF}/html\\\"" + mycc="${mycc} -DDEF_QUEUE_DIR=\\\"/var/spool/postfix\\\"" + mycc="${mycc} -DDEF_DATA_DIR=\\\"/var/lib/postfix\\\"" + mycc="${mycc} -DDEF_MAIL_OWNER=\\\"postfix\\\"" + mycc="${mycc} -DDEF_SGID_GROUP=\\\"postdrop\\\"" + # Robin H. Johnson <robbat2@gentoo.org> 17/Nov/2006 # Fix because infra boxes hit 2Gb .db files that fail a 32-bit fstat signed check. mycc="${mycc} -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE" I really do not see your point removing this. This is very simple and make the parameters in line with those passed to the postfix-install command line. Providing different defaults at compile and install steps is just broken... And I repeat again and again, but this was fine with the 2.8 series !!
Just thought about an other way to show the problem: - stock postfix "postconf -d" run, and you *can* change it using main.cf - gentoo postfix-2.8 "postconf -d" run, and you *can* change it using main.cf - gentoo postfix-2.9.0 "postconf -d" do *not* run, and you *have to* change default in your main.cf (hardcoding system path in it) to make it run. Still do not see any packaging issue shown like this ? I do. Please at least explain why you do not want to restore the "gentoo 2.8" and stock postfix behaviour instead of just closing "wontfix".
I hesitated to reopen but... Please, do not close it again without fixing it nor giving some good reason not to fix it. Until now, you said nothing more than just "I do not want to fix it". That is not a good argument... (And forget about comment 5, this is just plain wrong, since default are *already* changed...) Please QA team, give your opinion about those broken compile time default. From my point of view, this impact the quality of the tree (that's why I involved you).
Just to make sure that I understand it, there are two possibilities to override the default location? At compile time by defining DEF_DAEMON_DIR, and at run time by defining daemon_directory in config files? And postfix-2.8.8.ebuild used to redefine both, whereas 2.9.0 redefines it at run time only?
I just ran into the same problem. The Postfix 2.9.0 ebuild installs all daemons into /usr/lib{,64}/postfix (like the 2.8 ebuild) but the default value for the directive 'daemon_directory' is the non-existing directory '/usr/libexec/postfix' (unlike the 2.8 ebuild / see 'postconf -d'). Hence Postfix 2.9.0 fails to start with my personal main.cf which does not set the 'daemon_directory' directive. A easy workaround for this issue is to set 'daemon_directory = /usr/lib{,64}/postfix' in your main.cf. Why do we install the daemons into a non-upstream directory but do not modify this configuration directive? I think that this behaviour breaks a lot of configurations and that it can easily be fixed. Thanks. By the way: The main.cf directive 'manpage_directory' is affected, too.
Postfix defaults change over time. When the built-in default changes, at the same time post-install is changed to make a compatibility update to main.cf that restores the old default, for sites that have relied on the old default behavior. Several versions later, the post-install code is removed. When we keep to postfix defaults, we get the above mostly-seamless upgrade path for free. If we do not keep the same defaults, we will have to duplicate the effort. If we do not duplicate the effort, Gentoo users will have less than optimal upgrade experience. Please do not complain of broken configuration if you do not run or ignore etc-upgrade/dispatch-conf after upgrading. @Ulrich: No, nothing to do with run time. Basically, OP wants to run postfix without specifying daemon_directory in main.cf. Well, it won't work. There is a reason these settings are specified in main.cf by default.
Alternative might be to keep the defaults and install the daemons to /usr/libexec/postfix instead of /usr/lib{,64}/postfix. Done without a revbump: + 05 Feb 2012; Eray Aslan <eras@gentoo.org> postfix-2.9.0.ebuild: + install daemons to /usr/libexec/postfix - bug #401911 + This should make everyone happy.
(In reply to comment #10) > Please QA team, give your opinion about those broken compile time default. > From my point of view, this impact the quality of the tree (that's why I > involved you). AFAIK we have only a very general policy on this, <http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap1>: | Your package, when complete and unmasked, is supposed to "just work" for | the end-user. Tweaking the installed product to get it to work should be | optional; thus you need to install the package with reasonable default | settings. It doesn't say if these default settings must be specified at compile time or via a configuration file. This choice is up to the maintainer, especially if the package comes with a non-standard build system (as in this case where there's no configure). No reason for QA to get involved here, in my view. (In reply to comment #14) > Done without a revbump: > > + 05 Feb 2012; Eray Aslan <eras@gentoo.org> postfix-2.9.0.ebuild: > + install daemons to /usr/libexec/postfix - bug #401911 Location of installed files has changed, so you should do a revision bump. Otherwise users reinstalling 2.9.0 (or installing it on several machines) may get surprises.
(In reply to comment #13) > Postfix defaults change over time. When the built-in default changes, at the > same time post-install is changed to make a compatibility update to main.cf > that restores the old default, for sites that have relied on the old default > behavior. > > Several versions later, the post-install code is removed. > > When we keep to postfix defaults, we get the above mostly-seamless upgrade path > for free. If we do not keep the same defaults, we will have to duplicate the > effort. If we do not duplicate the effort, Gentoo users will have less than > optimal upgrade experience. > > Please do not complain of broken configuration if you do not run or ignore > etc-upgrade/dispatch-conf after upgrading. > > @Ulrich: > No, nothing to do with run time. Basically, OP wants to run postfix without > specifying daemon_directory in main.cf. Well, it won't work. There is a > reason these settings are specified in main.cf by default. Of course yes it has to do with run time VS compile time default and providing broken compile time default! Where do you see daemon_dir is mandatory to fix some broken compile_time default ? Nowhere. You tell there is a reason, but I always wait to ear for it... Again, it's not a matter of etc-update, it's about providing broken compile time defaults. And about the post-install script that "magically" update the main.cf: if the compile time default is correct, you do not need to have hardcode system path in main.cf (run time config) and thus you do not have to magically update it, and update runs seamlessly without changing one line of your configuration. I do not see any effort duplication here... Anyway, thanks for the change.
(In reply to comment #15) > | **thus you need to install the package with reasonable default > | settings.** > > It doesn't say if these default settings must be specified at compile time or > via a configuration file. This choice is up to the maintainer, especially if > the package comes with a non-standard build system (as in this case where > there's no configure). No reason for QA to get involved here, in my view. Here I think that broken compile-time default provided is a QA issue. Anyway, if you are fine with providing broken compile-time default that have to be overridden in config file (contrary to upstream version that do not need this override), fine. I stop with this.
