emerge/portage can't handle the case where the "ithreads" use flag on perl is enabled when using getbinpkg in FEATURES. The reason is that getbinpkg does not see a use flag change on the module itself and installs the binary version of the module (which goes to a different install location on non-threaded perl opposed to perl with ithreads enabled). If perl then searches for the module it cannot find it. It should have been installed not from source. To fix this we either need some global use flag on all affected perl modules (so binpkg sees a change in flags) or some way to permanently exclude all dev-perl and virtual/perl-* packages from a build which is not supported by emerge afaik Reproducible: Always Steps to Reproduce: 1. enable getbinpkg on FEATURES or EMERGE_DEFAULT_OPTS in /etc/portage/make.conf 2. enable "ithreads" use flag on perl and emerge it 3. try to install any binary perl package (for example XML::Parser) which install in wrong location Actual Results: all binary perl packages are not compatible with ithreads use-flag on perl and getbinpkg. It breaks the system Expected Results: Some way that perl-modules are excluded from getbinpkg if ithreads is enabled.
This is a frustrating one because it mostly doesn't matter for source builds (we warn the user on dev-lang/perl changing flags and then that's good enough really), but for binpkgs, you could have contaminated your cache and not realise until a while after. I agree this makes it more pressing. If we can't fix bug 680496 any time soon, I tthink a global USE or something would be better than nothing.
(In reply to Sam James from comment #1) > This is a frustrating one because it mostly doesn't matter for source builds > (we warn the user on dev-lang/perl changing flags and then that's good > enough really), but for binpkgs, you could have contaminated your cache and > not realise until a while after. > > I agree this makes it more pressing. If we can't fix bug 680496 any time > soon, I tthink a global USE or something would be better than nothing. My suggestion would be a USE_EXPAND PERL_FEATURES="debug ithreads quadmath" which is auto-added by the eclass, and adds the corresponding runtime/buildtime dependency on perl ... i.e. perl_features_quadmath => require dev-lang/perl[quadmath] and so on
https://github.com/gentoo/gentoo/pull/36349 ^ Ongoing work here...
commit 210cf01585ee780b4c075624006e900f4c404224 Author: Andreas K. Hüttel <dilfridge@gentoo.org> Date: Tue May 7 09:53:36 2024 +0200 dev-lang/perl: slow down warning countdown Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> commit 0f6f8b61641a0035680ab5858e5d47cd2b3c53b2 Author: Andreas K. Hüttel <dilfridge@gentoo.org> Date: Wed May 1 20:36:29 2024 +1100 profiles: use.mask perl_features_debug Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> commit fc4b35b62d9846c2f5c157225cb35f295badf73a Author: Andreas K. Hüttel <dilfridge@gentoo.org> Date: Mon Apr 22 11:57:53 2024 +1100 perl-module.eclass: Implement dependency on PERL_FEATURES Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> commit 47bd83af8cd0b0bdb60995e40417f3d5660e1c7d Author: Andreas K. Hüttel <dilfridge@gentoo.org> Date: Sun Apr 21 23:10:00 2024 +1100 www-apache/mod_perl: Port to PERL_FEATURES Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> commit be340afd975a309999d17ecd648e07f377487953 Author: Andreas K. Hüttel <dilfridge@gentoo.org> Date: Sun Apr 21 23:04:17 2024 +1100 virtual/perl-threads: Port to PERL_FEATURES Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> commit bb01d60a9212281ed6bdb95e1f5ddc8ffda35e00 Author: Andreas K. Hüttel <dilfridge@gentoo.org> Date: Sun Apr 21 23:01:35 2024 +1100 net-analyzer/snortalog: Port to PERL_FEATURES Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> commit 0dabc18c770a8efa5c9a40dce6a81c35e870aca8 Author: Andreas K. Hüttel <dilfridge@gentoo.org> Date: Sun Apr 21 22:29:13 2024 +1100 media-sound/cantata: Port to PERL_FEATURES Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> commit b94387ffaef892cfe3551d871decf34d0e6b8635 Author: Andreas K. Hüttel <dilfridge@gentoo.org> Date: Sun Apr 21 22:26:08 2024 +1100 app-metrics/collectd: Port to PERL_FEATURES Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> commit ae758a36dbb676619430a911300ba32f5f13e286 Author: Andreas K. Hüttel <dilfridge@gentoo.org> Date: Sun Apr 21 22:21:55 2024 +1100 app-editors/padre: Port to PERL_FEATURES Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> commit 85e6571079557aa9d8ee6971ef3e09028f3137ed Author: Andreas K. Hüttel <dilfridge@gentoo.org> Date: Fri Apr 19 22:59:07 2024 +1100 dev-lang/perl: Migrate to PERL_FEATURES Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> and commit 9b2a821e455c662000a56f630fd0c38b397e7cb8 (HEAD -> master, origin/master, origin/HEAD) Author: Andreas K. Hüttel <dilfridge@gentoo.org> Date: Tue May 7 11:32:25 2024 +0200 2024-05-07-perl rev. 2: fix posted date Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> commit 4b348e89b0b705b97c0582eeca0bab2435c4d778 Author: Andreas K. Hüttel <dilfridge@gentoo.org> Date: Tue May 7 09:50:54 2024 +0200 Add 2024-05-07-perl-features-use-expand Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
commit d7c1ec61e1b52ff53b7bd917f86cb49d34d90277 Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: Thu May 16 23:40:30 2024 +0200 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: Thu May 16 23:40:30 2024 +0200 dev-lang/perl: drop 5.38.2-r2, 5.38.2-r4 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> dev-lang/perl/perl-5.38.2-r2.ebuild | 834 ----------------------------------------------------------------------------------------------------------------------------------------------------------------- dev-lang/perl/perl-5.38.2-r4.ebuild | 860 ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- 2 files changed, 1694 deletions(-)
Really unhappy about this "solution". I understand the reasoning behind it but the execution absolutely leaves to be desired as it causes depclean to fail on perl modules that aren't even affected by this USE flag change and as a result are not identified for rebuild by perl-cleaner. This should have been tested more thoroughly before dumping it on the community. Please do not make such hasty decisions again.
(In reply to Gordon Bos from comment #6) > Really unhappy about this "solution". I understand the reasoning behind it > but the execution absolutely leaves to be desired as it causes depclean to > fail on perl modules that aren't even affected by this USE flag change and > as a result are not identified for rebuild by perl-cleaner. This should have > been tested more thoroughly before dumping it on the community. Please do > not make such hasty decisions again. It was proposed and discussed on the mailing lists. You can dislike something without being rude. Anyway, no: 1) there was no real alternative other than the (unspecified, to-be-determined change) to a future EAPI; 2) portage needs to be able to rebuild most Perl packages at any point to avoid conflicts anyway; 2) this is the same effect as perl-cleaner would have. If perl-cleaner is wrongly not identifying things as needing a rebuild, please file a new bug - thanks.
Excuse me? Rude? I have noticed a conflict between depclean and perl-cleaner that you clearly did not verify before releasing this. There is also no point in filing a new bug report on this because reverting it will cause the exact same damage a second time. And talking about a bug, this wasn't even one. It was a configuration error that should never have been treated as a bug in the first place. I'm sure that the person that reported it is extremely happy with this solution but the way it was implemented caused a lot of trouble for everyone else having any of the affected flags set on Perl.
(In reply to Gordon Bos from comment #8) > Excuse me? Rude? > You talked about "dumping" a change on the community, and said it was a "hasty decision". It was neither. You can report an issue without being derogatory. > I have noticed a conflict between depclean and perl-cleaner that you clearly > did not verify before releasing this. There is also no point in filing a new > bug report on this because reverting it will cause the exact same damage a > second time. Who said we're going to revert it as a result? We would likely enhance perl-cleaner to handle it? > > And talking about a bug, this wasn't even one. It was a configuration error > that should never have been treated as a bug in the first place. I'm sure > that the person that reported it is extremely happy with this solution but > the way it was implemented caused a lot of trouble for everyone else having > any of the affected flags set on Perl. No, this *was* a bug, because the ABI required and path used wasn't encoded in the packages. It's something we've known about for ages but avoided dealing with. This tipped us over the edge.
(In reply to Gordon Bos from comment #8) > Excuse me? Rude? Yes, clearly rude.
> > Who said we're going to revert it as a result? We would likely enhance > perl-cleaner to handle it? > You should have done that before. The way you did it now forces users to manually reinstall perl modules because both emerge and perl-cleaner won't select them for rebuild but depclean next uses the -perl_feature_* flags on these modules to require these flags to also be disabled on Perl itself and then of course the next set of modules wants this setting back. I've had an update script on a headless machine compiling Perl and modules over and over again for over two weeks because of this.
Oh and binpkg on perl modules is prone to unexpected results. I know this because I run my own binhost to serve cross-compiled packages to ARM devices. If you cross-compile Perl then its system paths get messed up. Same, if you cross-compile Perl modules they will end up in HOST arch instead of TARGET arch. e.g. if I cross-compile EV I end up with * /usr/lib/perl5/vendor_perl/5.38/i686-linux-thread-multi/auto/EV/EV.so instead of * /usr/lib/perl5/vendor_perl/5.38/armv5tel-linux-thread-multi/auto/EV/EV.so And yes I use a 32 bit crossdev machine for a 32 bit target because otherwise lib would come out as lib64 and not just with Perl. This band-aid for one specific use case doesn't fix any of that. If you select a binhost you need to make sure to select one that matches your architecture. If @melser_regs is aware that the bin packages offered by his selected binhost are incorrect for his system then he should have selected a different binhost that does offer correct packages. Water under the bridge, but a better approach would have been to let emerge handle this when processing bin packages. After all it is not the module or even the associated library that is wrong but only the vendorarchpath that can easily be altered between unpack and merge.
Feel free to file a bug if further changes are needed, ideally in a polite manner. I don't think further dialogue is helpful here. Thanks.
I don't really know what according to you is inappropriate behaviour, but I'm sure I'm a couple of hours ahead of you and on my side of the big pond we don't normally do American fake social protocols. And no I'd rather not see you make any further changes with respect to this topic. My request to you all was to be more considerate and prior to releasing verify that whatever solution you came up with does not create a bigger problem for a much larger group of users. Since two of you instantly stated this more than reasonable request to be rude, I guess I got my answer. You won't.
No, I'm in Europe too. You said it was "dumped" and "hasty". It was neither. It's OK to say a change had bugs (although I'm not convinced there was one here), but there's no need to imply it was done carelessly.
(In reply to Gordon Bos from comment #12) > Oh and binpkg on perl modules is prone to unexpected results. I know this > because I run my own binhost to serve cross-compiled packages to ARM > devices. If you cross-compile Perl then its system paths get messed up. > Same, if you cross-compile Perl modules they will end up in HOST arch > instead of TARGET arch. > Cross-compilation with Perl is known to be borderline-impossible to do correctly with no icky parts, unfortunately. This is, in part, a consequence from how some of its build systems work. This does not mean that binpkgs with Perl modules are in general not something to try to support. > e.g. if I cross-compile EV I end up with > * /usr/lib/perl5/vendor_perl/5.38/i686-linux-thread-multi/auto/EV/EV.so > instead of > * /usr/lib/perl5/vendor_perl/5.38/armv5tel-linux-thread-multi/auto/EV/EV.so > > And yes I use a 32 bit crossdev machine for a 32 bit target because > otherwise lib would come out as lib64 and not just with Perl. This band-aid > for one specific use case doesn't fix any of that. It's not supposed to. It's supposed to handle the ABI variants from different USE not being reflected in binpkgs. Having a binpkg "not know" if it was built against perl[ithreads] or not is a problem. That's what was fixed here, using the only available mechanism (as subslots can't contain USE). As I said, you may disagree with the change (although it's still not clear to me what specifically is wrong yet), but the change itself was both something planned for ages and also reasonable here. You can see many other examples of this in the See Also'd bug too. But I do accept it's possible it had some unintended side-effect for you - it just doesn't mean it was "dumped" or done in "haste". You could just report that without the frustration elemnt, and we can discuss it.
> It's not supposed to. It's supposed to handle the ABI variants from > different USE not being reflected in binpkgs. Having a binpkg "not know" if > it was built against perl[ithreads] or not is a problem. That's what was > fixed here, using the only available mechanism (as subslots can't contain > USE). I don't think you fully grasped the "issue" that was reported. Any module that supports multithreading will have the ithreads USE flag defined and if these flags don't match with the target system then emerge will reject the binpkg and call for a local ebuild. The "trouble" that reporter encountered was with modules that do not support multithreading at all and thus do not declare the ithreads USE flag. This causes the binpkg to be accepted on both multithreaded and single threaded installations and obviously on one of them the vendorarch path will be wrong because that's how Perl organizes it. This was never a Gentoo issue and all that you "fixed" for the reporter is that emerge will now instantly reject everything Perl from the binhost rather than him needing to ebuild it locally anyway afterwards. Like I said before, it's a configuration error and he should have selected a different binhost that does offer packages that are right for his system rather than report it here as a bug which it never was but still got treated that way.
> I've had an > update script on a headless machine compiling Perl and modules over and over > again for over two weeks because of this. We are not responsible for your scripting failures. > I don't think you fully grasped the "issue" that was reported. Any module > that supports multithreading will have the ithreads USE flag defined Nope. No modules ever had that useflag. > This was never a Gentoo issue and all that you "fixed" for the reporter is > that emerge will now instantly reject everything Perl from the binhost Nope. The binhost right now does not have packages for PERL_FEATURES="ithreads", which is a bit too selective (it would only strictly be necessary for modules installing into the arch-specific directory). That may change though. > before, it's a configuration error and he should have selected a different > binhost that does offer packages that are right for his system rather than > report it here as a bug which it never was but still got treated that way. No.
(In reply to Sam James from comment #15) > No, I'm in Europe too. You said it was "dumped" and "hasty". It was neither. > It's OK to say a change had bugs (although I'm not convinced there was one > here), but there's no need to imply it was done carelessly. The news item on this change is less than three weeks after the initial report. You also stated yourself that you were already playing with the idea to override Perl's behaviour to create arch feature specific paths and "this tipped us over the edge". I've rarely seen anything being picked up so fast and especially not a non-issue. Thus I still say you were too eager, especially since this change doesn't do anything for your stated intention. It only fixes an annoyance for someone who chose the wrong binhost.
It's okay to accept that you are wrong and stop replying to this closed bug. It's okay to open a new bug if you have something useful to add. Be well.
(In reply to Andreas K. Hüttel from comment #18) > > I've had an > > update script on a headless machine compiling Perl and modules over and over > > again for over two weeks because of this. > > We are not responsible for your scripting failures. I didn't create the script and it ran flawlessly for at least six years. > > I don't think you fully grasped the "issue" that was reported. Any module > > that supports multithreading will have the ithreads USE flag defined > > Nope. No modules ever had that useflag. You are completely missing the argument > > This was never a Gentoo issue and all that you "fixed" for the reporter is > > that emerge will now instantly reject everything Perl from the binhost > > Nope. Cherry picking, moving forward on what you missed in the first place > The binhost right now does not have packages for PERL_FEATURES="ithreads", > which is a bit too selective (it would only strictly be necessary for > modules installing into the arch-specific directory). Definitely not getting it at all. The eclass enforced USE flag inclusion just causes emerge to reject installing a binpkg that doesn't match all and revert to doing a local ebuild right away rather than user that chose the wrong binhost to fix his own error. > That may change though. > > > before, it's a configuration error and he should have selected a different > > binhost that does offer packages that are right for his system rather than > > report it here as a bug which it never was but still got treated that way. > > No. Yes it was. You are just too stubborn to acknowledge that this is a Perl induced problem that you will never be able to fix on the Gentoo side.
(In reply to Greg Kubaryk from comment #20) > It's okay to accept that you are wrong and stop replying to this closed bug. > It's okay to open a new bug if you have something useful to add. Be well. Good for you, I like people that have an opinion. I like people that can substantiate them even more. My absolute favourite people however are those that don't consider facts to be open for discussion.
> I don't really know what according to you is inappropriate behaviour, but I'm sure I'm a couple of hours ahead of you and on my side of the big pond we don't normally do American fake social protocols. I'm from the land above your swamp, so let me be blunt. Read the room. Anything you are doing to yourself here is making sure that everyone is fully aware to ignore anything you say going forward.
(In reply to Paul Zander from comment #23) > > I don't really know what according to you is inappropriate behaviour, but I'm sure I'm a couple of hours ahead of you and on my side of the big pond we don't normally do American fake social protocols. > > I'm from the land above your swamp, so let me be blunt. Read the room. > Anything you are doing to yourself here is making sure that everyone is > fully aware to ignore anything you say going forward. Right, so you figured that if someone is "rude" enough to point out that an error in judgement was made, you should show actual rudeness by insulting a country.
Quite telling how you claim you don't do "American fake social protocols", but immediately think that "swamp germany" was meant as an insult.
(In reply to Paul Zander from comment #25) > Quite telling how you claim you don't do "American fake social protocols", > but immediately think that "swamp germany" was meant as an insult. Which just goes to show that you don't know anybody on the other side of the pond and consider them lesser people that are incapable of defending themselves, therefore "needing" you to jump to their cause.
Gordon, please stop ranting in this thread, it's now very far away from the topic. FYI I'm the original requester and I think the way it was solved is exactly how it should work and not just for me. I know you disagree and that's fine and there's a saying "you can never please everyone". It's clear that the change did not please you. You say it was my fault that I selected a wrong binhost, but you couldn't be more wrong on this. There's official docs for "gentoo boing binary" which I followed and they tell you which are the official binhosts you can use for your arch and I used that. If you're running your own binhost to cross-compile and serve packages to ARM devices you have to agree that's a very specialised setup. Definitly not something the average gentoo user is doing and you cannot expect me or anyone else to host it's own binhost just because the official binhost did something wrong which was the case here. In this case the packages on the binhost should be fixed as I as a user cannot do it and I should not. FYI: They way the official binhost works is that if you change the use flag it will source compile the packages instead of installing them from the binhost. This just didn't work for perl packages. If I enabled "ithreads" it detected that change and source compiled perl itself changing the module install location but there was no use flag change on the modules so it installed the binary module packages from the official host and you couldn't even prevent this breaking the perl installation if you did choose to use official binary packages. And that the devs created a problem for a much bigger group of users I highly doubt. Firstly because most people probably don't even use "ithreads" and secondly because most people don't run a binhost with "ithreads" enabled custom built packages which install into correct location. So you're the exception not the majourity as you're running a very specific setup. Your complaining because your script worked for 6 years but now it broke because of the change. But as the devs said they are not responsible for your script it doesn't matter how long it worked before especially with your higly customized setup. And you got the news on "eselect" and you could have checked your script instead of just let it run for weeks. That's your omissions not having checked it at all when these changes were announced. As you probably know it's quite common that you have to take action on news items, the change is not different at all. Furthermore I do agree with all other posters here that you're an extremly rude person. Let alone the last few comments in this thread. You're claiming that the devs are extremly stubborn but what about you. You're the most stubborn person here in this thread that somehow feels the need to defend himself and cannot accept that his comments are rude and the he should maybe think of his attitude. And just as closing words - I'm from over the pond located in central europe and I never felt that people from other countries no matter which one have treated me like I'm a lesser person nor did the devs. That's just your weird pereceoption. And in the end it was you that started the thread to become more policital and personal with your statement about "fake american protocols". I guess you will now again file another big disagreeement post and the need to further defend youself instead of thinking about your posts and attitude. Be my guest. I don't follow this thread any longer and also created an e-mail rule to delete mails from this bug as it CLOSED and FIXED
*** Bug 933413 has been marked as a duplicate of this bug. ***
> I guess you will now again file another big disagreeement post and the need > to further defend youself instead of thinking about your posts and attitude. > Be my guest. I don't follow this thread any longer and also created an > e-mail rule to delete mails from this bug as it CLOSED and FIXED So in effect ring and run... Like you said, you won't read it but I'll still say it for everyone that doesn't bury his head in the sand: as Andreas stated you did NOT receive your desired fix in any way. In fact what Andreas said is that they can't fix it for you, ever, because "it's too specific". Gentoo going binary? I did binary Gentoo some 15 years ago as a side step to go desktop, it was called Sabayon and regular updates rendered my system unbootable or without graphics so many times that I lost count. I guess my hardware was "too specific" for the maintainers of those packages as well. Unless they decide to retire portage you should still be okay though as portage will cause the majority of packages to still be compiled locally either because of a USE flag mismatch or some obscure changed dependency. BTW the failing part of the script I use is the call to emerge --autounmask Told you I didn't write the script that is failing, Gentoo devs wrote it.
(In reply to melser_regs@gmxpro.net from comment #27) > FYI: They way the official binhost works is that if you change the use flag > it will source compile the packages instead of installing them from the > binhost. This just didn't work for perl packages. Explaining to me what I explained myself only proves that you didn't actually read a single word I wrote. YES! It doesn't work with Perl because Perl expects modules to be in a path that reflects both the system architecture and features it was compiled with. As I stated in my initial "rude" post, I understand the reasoning behind it with respect to the use of a binhost, but the execution is absolutely flawed and I'm sure I worded that last bit in an absolute nicer and non-rude way.
(In reply to Gordon Bos from comment #30) > Perl expects modules to be in a path that reflects both the system > architecture and features it was compiled with. As I stated in my initial > "rude" post, I understand the reasoning behind it with respect to the use of > a binhost, but the execution is absolutely flawed and I'm sure I worded that > last bit in an absolute nicer and non-rude way. The execution was quite straightforward and works for everyone other than you, and it would have worked for you as well if you took heed of the fact that when you are required to read a news item or tell portage that you refuse to read it, you are advised to... read it. The features that it was compiled with -- sure sounds like a USE flag to me. And lo and behold, perl used the standard gentoo technology: USE flags. (In reply to Gordon Bos from comment #29) > BTW the failing part of the script I use is the call to > > emerge --autounmask > > Told you I didn't write the script that is failing, Gentoo devs wrote it. Nifty! Per the man page: > If the displayed configuration changes are satisfactory, you should copy > and paste them into the specified configuration file(s), or enable the > --autounmask-write option. Also: > --autounmask-continue > > WARNING: This option is intended to be used only with great caution, > since it is possible for it to make nonsensical configuration changes > which may lead to system breakage. Therefore, it is advisable to use > --ask together with this option. The Gentoo devs who "wrote" your script were very, very, very clear that --autounmask should not be used in an unmonitored fashion, and that "nonsensical configuration changes which may lead to system breakage" are a ***reasonable outcome*** of using the script which did, indeed, produce nonsensical configuration changes and fail. As the Gentoo devs warned you, so it has happened. This is what you get for not reading the docs. You didn't read the eselect news docs. You didn't read the docs for the "autounmask script" (/usr/bin/emerge) which you used. You paid the price of not reading the docs.
(In reply to Eli Schwartz from comment #31) > The execution was quite straightforward and works for everyone other than > you, and it would have worked for you as well if you took heed of the fact > that when you are required to read a news item or tell portage that you > refuse to read it, you are advised to... read it. > > The features that it was compiled with -- sure sounds like a USE flag to me. > And lo and behold, perl used the standard gentoo technology: USE flags. Regular updates don't normally call for USE flag updates, thus I concur with the original author of the update script that autounmask is to be considered safe for scheduled updates on a headless machine. Apparently I am very bad at explaining something in English, or non-native readers get lost in their own translation. It's not about autounmask. Autounmask merely allowed the update script I use to enter a never ending loop based on a bad instruction from portage. It is this instruction from portage that used to be correct but on account of this change no longer is. i.e. if on a system with single-threaded Perl you install a package that wants multi-threaded Perl portage would instruct you to add the following to package.use: =dev-lang/perl-<version> ithreads Which is correct, except as a user you will likely want to remove the version specification. Now, given the same situation portage will instruct you to add the following instead: =dev-lang/perl-<version> perl_features_ithreads And that is wrong because when portage now touches a package that includes the perl-module eclass the user will next be prompted to add this: =dev-lang/perl-<version> -perl_features_ithreads And then of course the package that started this wants the USE flag back, and then it needs to go again, and back, and gone, and ... Now if any of you can direct me to where in the Gentoo docs it is stated that if portage instructs you to add USE flag foo_bar to some named package this needs to be interpreted as needing to add FOO=bar in make.conf I'll grant that you are all correct and I was wrong. I'll then still call for a feature change though that portage gives clear instructions that a novice can understand as well. If however you can't, because no such paragraph exist, I'd appreciate you all to stop the verbal abuse and use your keyboards for something constructive instead. Deal?
(In reply to Gordon Bos from comment #32) > (In reply to Eli Schwartz from comment #31) > > The execution was quite straightforward and works for everyone other than > > you, and it would have worked for you as well if you took heed of the fact > > that when you are required to read a news item or tell portage that you > > refuse to read it, you are advised to... read it. > > > > The features that it was compiled with -- sure sounds like a USE flag to me. > > And lo and behold, perl used the standard gentoo technology: USE flags. > > Regular updates don't normally call for USE flag updates, thus I concur with > the original author of the update script that autounmask is to be considered > safe for scheduled updates on a headless machine. This is an incorrect belief, both you and the original author of the update script are wrong -- assuming the original author of the update script ever said what you said. Previously, you claimed the update script was authored by the gentoo devs, and that said update script is called "emerge" -- this is clearly untrue if you claim the update script's authors say autounmask is considered safe, since the emerge authors explicitly claim it is unsafe. Also, *anyone* who says it is considered safe, or concurs that it is considered safe, is wrong because the emerge manpage says it is unsafe. There is nothing else to discuss about the safety or otherwise of autounmask. > Apparently I am very bad at explaining something in English, or non-native > readers get lost in their own translation. It's not about autounmask. > Autounmask merely allowed the update script I use to enter a never ending > loop based on a bad instruction from portage. It is this instruction from > portage that used to be correct but on account of this change no longer is. > > i.e. if on a system with single-threaded Perl you install a package that > wants multi-threaded Perl portage would instruct you to add the following to > package.use: Since autounmask is not safe, and its recommendations are only potential suggestions that must be reviewed for correctness before applying, it is illogical to claim that the instruction is bad. It is illogical to claim that the instruction used to be correct but no longer is. > Now, given the same situation portage will instruct you to add the following > instead: > > =dev-lang/perl-<version> perl_features_ithreads > > And that is wrong because when portage now touches a package that includes > the perl-module eclass the user will next be prompted to add this: > > =dev-lang/perl-<version> -perl_features_ithreads > > And then of course the package that started this wants the USE flag back, > and then it needs to go again, and back, and gone, and ... No -- the instruction is correct, but incomplete. Both are possible (incomplete) resolutions, both are valid changes a user might wish to make depending on whether they want ithreads support. If a user interacts with the autounmask hints rather than automating their acceptance, the user will realize that this is what the `eselect news` talked about. It all comes back to this one simple problem: People are supposed to read the news when emerge asks them to, and if they don't read the news, they can get in trouble, which is what you did. > Now if any of you can direct me to where in the Gentoo docs it is stated > that if portage instructs you to add USE flag foo_bar to some named package > this needs to be interpreted as needing to add FOO=bar in make.conf I'll > grant that you are all correct and I was wrong. I'll then still call for a > feature change though that portage gives clear instructions that a novice > can understand as well. > > If however you can't, because no such paragraph exist, I'd appreciate you > all to stop the verbal abuse and use your keyboards for something > constructive instead. Deal? I'm not going to claim that the Gentoo docs say a Straw Man Fallacy: https://en.wikipedia.org/wiki/Straw_man You can have your strawman back and put it back where you originally found it, thanks. "if portage instructs you to add USE flag foo_bar to some named package this needs to be interpreted as needing to add FOO=bar in make.conf" is obviously incorrect and Gentoo never claimed any such thing, nor would it ever make sense to claim such a thing, because... that would imply that all FOO=bar are the same, when they are not. Some FOO=bar need to be set in make.conf, some need to be set in package.use, and some can be set in both, depending on what the user wishes. By that same token, portage cannot give clear instructions that a novice can understand as well. But guess what can give clear instructions that a novice can understand as well? eselect news News posts can give clear instructions, and Gentoo released a news post about this topic, and everyone, novice and experienced user alike, managed to figure out what to do. Other than you. And that's on you for not reading the news when emerge told you to read the news. (It is also on you for using something risky and unpredictable like autounmask hints, but well...) In short: when emerge tells you to read the news, read the news.
(In reply to Eli Schwartz from comment #33) > In short: when emerge tells you to read the news, read the news. Right... So you decline the deal and feel the need to take the foul mouthing even further while at the same time showing that: a) You have no clue whatsoever that a headless system does not have any user interface, neither input nor output. b) You have no understanding whatsoever that PERL_FEATURES=ithreads and USE=perl_features_ithreads are not only interchangeable but that from within portage it is impossible to say which one of the two was declared. c) That news is only presented when portage detects, or rather is able to detect, that it applies to your system. I short: you crashed and burned on what you thought to be an easy target. Goodbye.
CC'ing comrel in hopes of ending this already closed bug that a certain user cannot stop replying to.
