Doing a world update or just doing an squid only update results in: ... done! [ebuild U ] net-proxy/squid-5.4.1-r1::gentoo [4.17::gentoo] USE="caps htcp ipv6 pam perl samba sasl sqlite ssl wccp wccpv2 -ecap -esi -gnutls -kerberos -ldap -logrotate -mysql -nis -postgres -qos -radius (-selinux) -snmp -ssl-crtd -systemd -test -tproxy" 2,502 KiB [blocks B ] <net-proxy/squid-5 ("<net-proxy/squid-5" is hard blocking net-proxy/squid-5.4.1-r1) Total: 1 package (1 upgrade), Size of downloads: 2,502 KiB Conflict: 1 block (1 unsatisfied) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (net-proxy/squid-5.4.1-r1:0/0::gentoo, ebuild scheduled for merge) pulled in by squid net-proxy/squid required by @selected Possible offending line from the ebuild is: RDEPEND="!!<net-proxy/squid-5
You need to manually uninstall your squid-4.17 installation before you can install squid-5 I suppose squid-5 would pick up something from your squid-4 installation during compilation rendering the resulting squid-5 broken.
More info here: https://forums.gentoo.org/viewtopic-p-8651905.html
There's nothing we can really do in time to help squid users on the Portage side right now, although I've filed bug 834600. I think we should probably just do a news item in this case. As others have noted, the blocker is valid.
NEWS is a good idea.
this is so bad :) I use squid on a slooooow production machine. building squid may take up to 2+ hours and such a downtime is quite painful for the proxy service. any hints as to how overcome this ? I can afford erasing all the soft links under the /usr/share/squid/errors/ directory cheers
here was my approach to this problem in order to minimize downtime. I compiled squid-5.4.1 from source & installed it under /usr/local I then switched the proxy service to the /usr/local/squid daemon (to my surprise my squid-4.conf had no issues) now that the proxy service is running, I can uninstall squid-4 & proceed with installing squid-5 my production server is on an 10watt system with a J1900 CPU :)
(In reply to Alexandros C. Couloumbis from comment #5) > this is so bad :) > > I use squid on a slooooow production machine. building squid may take up to > 2+ hours and such a downtime is quite painful for the proxy service. > > any hints as to how overcome this ? I can afford erasing all the soft links > under the /usr/share/squid/errors/ directory > > cheers You can build a binary package in advance (maybe even cross-compile on a faster machine).
(In reply to Tomáš Mózes from comment #7) > > You can build a binary package in advance (maybe even cross-compile on a > faster machine). one of the reasons I still use gentoo (& not Void linux for example) on my servers, is the feature & ability to compile every bit of code on the machine that runs the services. cross-compile environment is something I don't have the luxury (& energy) currently to afford. regards & thank you much for the feedback.
(In reply to Alexandros C. Couloumbis from comment #8) > (In reply to Tomáš Mózes from comment #7) > > > > You can build a binary package in advance (maybe even cross-compile on a > > faster machine). > > one of the reasons I still use gentoo (& not Void linux for example) on my > servers, is the feature & ability to compile every bit of code on the > machine that runs the services. > > cross-compile environment is something I don't have the luxury (& energy) > currently to afford. > > regards & thank you much for the feedback. Unfortunately that's the kind of tradeoff one has to pay when using Gentoo on a slow (low power) machine. For example, my Intel Atom systems take more than eight hours to compile recent gcc releases. That's where either a strong/fast build host comes handy or you sometimes have to deal with some service outages.
*** Bug 891115 has been marked as a duplicate of this bug. ***
(In reply to Tomáš Mózes from comment #2) > More info here: https://forums.gentoo.org/viewtopic-p-8651905.html Well, then maybe fixing emerge would be a good idea.
(In reply to Laszlo Valko from comment #11) > (In reply to Tomáš Mózes from comment #2) > > More info here: https://forums.gentoo.org/viewtopic-p-8651905.html > > Well, then maybe fixing emerge would be a good idea. Patches welcome. I sympathise, and this is a frustrating bug, but at the same time, it's also not particularly easy to solve.
I'm looking into a pkg_preinst hackaround.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0ae592744da6c4b5cd96f1b92d4f92cc23f9dbcc commit 0ae592744da6c4b5cd96f1b92d4f92cc23f9dbcc Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2023-01-16 20:12:33 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2023-01-16 20:28:47 +0000 net-proxy/squid: add workaround for 4.x to 5.x upgrade Move /usr/share/squid/errors out of the way to avoid triggering an error from Portage when replacing symlinks with directories. We must do this in pkg_setup because the Portage safety check runs before pkg_preinst. Closes: https://bugs.gentoo.org/834503 Signed-off-by: Mike Gilbert <floppym@gentoo.org> net-proxy/squid/squid-5.7.ebuild | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6378dbf5695a3344e071a6d14eeb63e172ea21a9 commit 6378dbf5695a3344e071a6d14eeb63e172ea21a9 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-01-18 21:47:09 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-01-18 21:49:00 +0000 net-proxy/squid: adapt symlink/dir replacement collision workaround Do it in src_install/pkg_preinst/pkg_postinst instead to reduce the window of fragility (if compile failed before for example, or did "ebuild ... clean configure", would have a half-migrated state). Bug: https://bugs.gentoo.org/834503 See: https://github.com/gentoo/gentoo/pull/29138 Signed-off-by: Sam James <sam@gentoo.org> .../{squid-5.7.ebuild => squid-5.7-r1.ebuild} | 31 ++++++++++------------ 1 file changed, 14 insertions(+), 17 deletions(-)
