Re: [gentoo-dev] Packages broken by phase ordering change
On Sat, 2008-06-14 at 15:09 +0100, Ciaran McCreesh wrote: On Fri, 13 Jun 2008 21:55:29 +0200 Santiago M. Mola [EMAIL PROTECTED] wrote: As discussed in bug #222721, portage has changed the execution order of phases. It seems the change was introduced in portage-2.1.5 and it makes that, when upgrading a package, pkg_postinst is run after the old version has been removed. This breaks packages which use has_version in pkg_postinst to detect upgrades/downgrades. It can also break packages in more subtle ways. Given that the number of affected ebuilds is so high, I'd say Portage should have to revert the changes... Of course, you would. What else would we expect from you? This is an EAPI scope change, if anything. Although even then the implications are a bit messy since you're talking the interaction of two different EAPIs. It seems that everything these days is an EAPI scope change. That's not very useful for Gentoo, considering it's been quite some time since PMS was proposed and we've not seen approval for either EAPI=0 or EAPI=1 (or PMS, for that matter). What we have gotten is a half-assed you can use EAPI=1 in the tree to get these enumerated features from the Council, but that's nothing like acceptance of a spec. Perhaps if you spent a little more time doing something more constructive than being an asshat on the lists, PMS would have been approved long ago. Of course, that doesn't mesh well with your apparent need to be a complete dick to people, so continue on with the status quo. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages broken by phase ordering change
On Wed, 18 Jun 2008 18:21:24 -0700 Chris Gianelloni [EMAIL PROTECTED] wrote: It seems that everything these days is an EAPI scope change. That's not very useful for Gentoo, considering it's been quite some time since PMS was proposed and we've not seen approval for either EAPI=0 or EAPI=1 (or PMS, for that matter). What we have gotten is a half-assed you can use EAPI=1 in the tree to get these enumerated features from the Council, but that's nothing like acceptance of a spec. Perhaps if you spent a little more time doing something more constructive than being an asshat on the lists, PMS would have been approved long ago. Of course, that doesn't mesh well with your apparent need to be a complete dick to people, so continue on with the status quo. +1 Kind regards, JeR -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Packages broken by phase ordering change
On Thursday 19 June 2008 02:21:24 Chris Gianelloni wrote: It seems that everything these days is an EAPI scope change. Everything change that has the potential to break existing packages, or to make new packages incompatible with existing package managers, is an EAPI scope change. That is the very purpose of EAPI. Perhaps if you spent a little more time doing something more constructive than being an asshat on the lists, PMS would have been approved long ago. Of course, that doesn't mesh well with your apparent need to be a complete dick to people, so continue on with the status quo. This thread was entirely technical until now. Are such attacks really necessary? -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Packages broken by phase ordering change
On Freitag, 13. Juni 2008, Santiago M. Mola wrote: Hi all, As discussed in bug #222721, portage has changed the execution order of phases. It seems the change was introduced in portage-2.1.5 and it makes that, when upgrading a package, pkg_postinst is run after the old version has been removed. This breaks packages which use has_version in pkg_postinst to detect upgrades/downgrades. It can also break packages in more subtle ways. So someone that has access permissions here: Please do fix the devmanual http://devmanual.gentoo.org/ebuild-writing/functions/pkg_postinst/index.html It now states: Common pkg_postinst Tasks The most common use for pkg_postinst is to display post-install informational messages or warnings. Note that has_version will operate on the version that was installed, which can be useful for selective upgrade messages. Regards Matthias -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Packages broken by phase ordering change
On Sun, Jun 15, 2008 at 12:32 PM, Matthias Schwarzott [EMAIL PROTECTED] wrote: On Freitag, 13. Juni 2008, Santiago M. Mola wrote: Hi all, As discussed in bug #222721, portage has changed the execution order of phases. It seems the change was introduced in portage-2.1.5 and it makes that, when upgrading a package, pkg_postinst is run after the old version has been removed. This breaks packages which use has_version in pkg_postinst to detect upgrades/downgrades. It can also break packages in more subtle ways. So someone that has access permissions here: Please do fix the devmanual http://devmanual.gentoo.org/ebuild-writing/functions/pkg_postinst/index.html https://bugs.gentoo.org/show_bug.cgi?id=226419 Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Packages broken by phase ordering change
Hi all, As discussed in bug #222721, portage has changed the execution order of phases. It seems the change was introduced in portage-2.1.5 and it makes that, when upgrading a package, pkg_postinst is run after the old version has been removed. This breaks packages which use has_version in pkg_postinst to detect upgrades/downgrades. It can also break packages in more subtle ways. The following ebuilds are affected by has_version problem. There may be some affected ebuilds missing, and also ebuilds broken in a different way. app-pda/libopensync-0.22 app-portage/conf-update-1.0 dev-libs/libotf-0.9.4 dev-libs/libotf-0.9.5 dev-libs/libotf-0.9.6 dev-libs/libotf-0.9.7 dev-util/scons-0.97 dev-util/scons-0.98.3 dev-util/scons-0.98.4 mail-filter/dspam-3.8.0-r11 media-gfx/splashutils-1.5.2.1 media-gfx/splashutils-1.5.3.4 media-gfx/splashutils-1.5.4 media-gfx/splashutils-1.5.4.1 media-gfx/splashutils-1.5.4-r1 media-libs/libdvbpsi-0.1.5 media-libs/libdvbpsi-0.1.6 media-libs/libexif-0.6.16 media-libs/libexif-0.6.16-r1 media-libs/pdflib-7.0.2 media-libs/pdflib-7.0.2_p8 media-plugins/vdr-epgsearch-0.9.19 media-plugins/vdr-epgsearch-0.9.20 media-plugins/vdr-epgsearch-0.9.21 media-plugins/vdr-epgsearch-0.9.22 media-plugins/vdr-epgsearch-0.9.23 media-plugins/vdr-epgsearch-0.9.24 media-plugins/vdr-epgsearch-0.9.24_beta19 media-plugins/vdr-epgsearch-0.9.24_beta22 media-plugins/vdr-epgsearch-0.9.24_beta23 media-plugins/vdr-epgsearch-0.9.24_beta26 media-plugins/vdr-epgsearch-0.9.24_rc2 media-tv/gentoo-vdr-scripts-0.4.0 media-tv/gentoo-vdr-scripts-0.4.1 media-tv/gentoo-vdr-scripts-0.4.2 media-tv/gentoo-vdr-scripts-0.4.3 media-tv/gentoo-vdr-scripts-0.4.3-r1 media-tv/gentoo-vdr-scripts-0.4.4 media-tv/vdrplugin-rebuild-0.2 media-video/vdr-1.4.6 media-video/vdr-1.4.7-r10 media-video/vdr-1.6.0 media-video/vdr-1.6.0_p1 media-video/vdr-1.6.0_p1-r1 media-video/vdr-1.6.0-r1 media-video/vdr-1.6.0-r2 net-analyzer/fail2ban-0.8.0-r1 net-analyzer/fail2ban-0.8.1 net-analyzer/fail2ban-0.8.2 net-dialup/ppp-2.4.4-r14 net-dialup/ppp-2.4.4-r15 net-firewall/iptables-1.3.5-r4 net-firewall/iptables-1.3.6 net-firewall/iptables-1.3.6-r1 net-firewall/iptables-1.3.7 net-firewall/iptables-1.3.8 net-firewall/iptables-1.3.8-r1 net-firewall/iptables-1.3.8-r2 net-firewall/iptables-1.3.8-r3 net-firewall/iptables-1.4.0 net-mail/getmail-4.7.6 net-mail/getmail-4.7.7 net-mail/getmail-4.7.8 net-mail/getmail-4.8.1 net-mail/mailgraph-1.14 net-misc/asterisk-1.2.13 net-misc/asterisk-1.2.13-r1 net-misc/asterisk-1.2.14 net-misc/asterisk-1.2.14-r1 net-misc/asterisk-1.2.14-r2 net-misc/asterisk-1.2.17 net-misc/asterisk-1.2.17-r1 net-misc/asterisk-1.2.21.1 net-misc/asterisk-1.2.21.1-r1 net-misc/asterisk-1.2.27 net-misc/freenet6-4.2.2 net-misc/freenet6-5.0 net-misc/freenet6-5.1 net-misc/ser-0.9.4 net-misc/ser-0.9.6 net-misc/ser-0.9.7 net-print/cups-1.2.12-r4 net-print/cups-1.2.12-r7 net-print/cups-1.2.12-r8 net-print/cups-1.3.7-r1 net-print/cups-1.3.7-r2 sys-cluster/util-vserver-0.30.214 sys-cluster/util-vserver-0.30.215 sys-fs/udev-114 sys-fs/udev-114-r1 sys-fs/udev-114-r2 sys-fs/udev-115 sys-fs/udev-115-r1 sys-fs/udev-115-r5 sys-fs/udev-115-r6 sys-fs/udev-116 sys-fs/udev-116-r1 sys-fs/udev-117 sys-fs/udev-118 sys-fs/udev-118-r1 sys-fs/udev-118-r2 sys-fs/udev-118-r3 sys-fs/udev-119 sys-fs/udev-119-r1 sys-fs/udev-120 sys-fs/udev-121 sys-fs/udev-122 sys-fs/udev-122-r1 sys-fs/udev-124 sys-process/vixie-cron-4.1-r10 www-client/surfraw-2.1.5 www-servers/apache-2.2.8 www-servers/apache-2.2.8-r3 www-servers/apache-2.2.8-r4 If the new phase order is staying, then all those packages should be fixed. It's possible to use has_version in pkg_setup or other phase and cache the result in a global variable. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
