RFE: news item for new build dependencies

[Hu]

There is only one person here resorting to public shaming and similar degenerate type behavior.

Maybe you're confining "here" to just this thread, but otherwise, I don't think that's a fair characterization. In the Qt 5.10 thread, several people were publicly shaming you for the post that provoked that thread.

[asturm]

but at least I do not have to expect abrupt breakage from someone tinkering in the main tree with stuff that should be getting tested in a staging area

Says the guy who recommended a dev overlay to a stable user... and no, I'm not perpetuating this for fun, but you keep repeating this 'staging' idea that I have to point out the flaw in your logic. And yes, similarly ~arch users are testing for arch.

It is sad that your temper gets in the way of otherwise very welcome contributions. Also, I sure would like to know more about those financial gains you mentioned... seems no one told me so far.

[Gibbo_07]

I'm just going to skip the drama and offer an unbiased opinion, or better a suggestion.

While I agree with those saying it's the users responsibility to check what's being merged, I also think there could be a system in place that collates important information regarding updates and makes it easily available in portage.

I'd find it very helpful to have portages news system offer some type of RSS feed about major updates, that could list the TOP bugs users might encounter during an upgrade, as well as show important notes from maintainers/project dev's.

Such an implementation would be a fantastic resource, as searching bugzilla, reading IRC or mailing lists to stay up to date is not possible for most users. Would certainly help with having less downtime by system breakages, less duplicate bugs posted, less backlash to the gentoo team etc.

Maybe it's some kind of delusional wish to some readers, however if there was someone willing to collate such information into a news feed, either in portage or a glsa-check type deal, there's nothing technically difficult about such a system.

[krinn]

What you are asking already exists, it's just NEWS feature of portage. And you can even read news already from https://www.gentoo.org/support/news-items

And you can see a lot of threads showing devs are lazy ass (i won't make friend again with asturm there, not because i'm saying he is a lazy ass, but you cannot critic any dev's work without asturm getting upset):
(kidding you asturm i do expect critic from you or anyone, because i don't think i'm always right and what i say could always be critic)
* viewtopic-t-1078672-highlight-.html
change to network handling breaking previous working installation, no news item, no ewarm... (i can't confirm myself the lack of ewarm/einfo but users didn't report any, and in the list of users, i see toralf and i gave him credits to check such things).
* viewtopic-t-1076204-highlight-udev.html
udev-adm new dependency over something from /usr which break /usr mount ; again no ewarn, no news. (i've check udev.ebuild, no warn in it).
note that, prior anyone crying that Council decision is applied, Council decision make such change valid only, in no way Council decision to not support /usr imply you are allow to fuck anyone system without a warning, even the decision do allow you to fuck their system).

These are the "recent" ones i remember, and as you see, in those two cases, users would had no way "from the list of package that would be emerge" to not fall into issue.

So, for me there, gentoo didn't fail, the tools exists, but gentoo devs has fail and didn't use existing tools.

[asturm]

(i won't make friend again with asturm there, not because i'm saying he is a lazy ass, but you cannot critic any dev's work without asturm getting upset)

Certainly not, that's a misrepresentation. But there's a very vocal minority here engaging in a permanent smear campaign, where I won't keep quiet. Feel free to PM me wherever you think you find an unjustified me being upset.

(kidding you asturm i do expect critic from you or anyone, because i don't think i'm always right and what i say could always be critic)

critique where critique is due

[krinn]

critique is also critique in french, and i was thinking it was a false-friend
writing this i'm thinking my "false-friend" may not be understood, in french it's when you use a french word that appears correct in another language while it's meaning is not the same.
like "issue", in french it's an exit where in english it's a problem.
hihi glad you get it my "critic" was "critique"

[Gibbo_07]

What you are asking already exists, it's just NEWS feature of portage. And you can even read news already from https://www.gentoo.org/support/news-items

If your reply was directed at me, then you really didn't understand my point.

The news feature averages ~14 news items per year. I'm talking about something that notifies of trending bugs from bugzilla etc. Something actually useful.

[krinn]

The news feature averages ~14 news items per year. I'm talking about something that notifies of trending bugs from bugzilla etc. Something actually useful.

There's no limit set to news items number to my knowledge, and it would do then the same as what you describe if news items were more use.

[asturm]

Something actually useful.

The news are *actually* useful. And they are already ignored too much.

@krinn: Spam factor aside, I disagree that one could lump the news together with 'trending bugs'. Bugs have a very temporary lifespan (ideally) while news items remain in the system for a relatively long time until even the last slacker has migrated from GCC-4/old ruby/old python/old Plasma/old Apache/etc. For trending bugs, ~arch users are affected by those most of the time, and, well, visit the forums and bugzilla, that works rather well imo without the need for someone curating them in the first place. Crafting news is a process of at least 48h, during which most grave, relevant bugs would already be fixed, and they are very seldomly cleaned out.

[Tony0945]

The news are *actually* useful. And they are already ignored too much.

Hey! We agree on something!

[krinn]

@krinn: Spam factor aside, I disagree that one could lump the news together with 'trending bugs'.

I'm not agreeing with that too, but bugs are not "features" ; changing something important in a package is not a bug, it's expect as you did change it, as such you should warn user about that.
I don't care someone is reporting a bug that udevadm cannot work anymore with /usr mount, but i do care the gentoo dev handling udev gives away a news stating: "warning new udevadm will no more work with /usr mount".
I'm happy with the news system, because when a dev use it, he generally not only reporting something, but gives some clues about possible solve, which is nice for users ; but number of news is just a proof news system is not use like it should, because none could believe only ~14 items were change with some critical changes in a year.

When i wish some kind of "RSS" ability of bugzilla, i just use the "show bug report/change in last 24 hours" in bugzilla.

[a.m]

In contrast, meson may be annoying, slow, or have other dependencies you don't like, but nothing you've said here leads me to think that a naive user needs to notice the new dependency. Users could happily emerge --update --deep @world, Portage would quietly install meson, it would be used, and the package would be built to completion.

I may not be naive enough, but this is definitely noticeable:

Code: Select all

!!! The ebuild selected to satisfy ">=dev-util/meson-0.40.0" has unmet requirements.
- dev-util/meson-0.44.1::gentoo USE="" PYTHON_TARGETS="-python3_4 -python3_5 -python3_6"

  The following REQUIRED_USE flag constraints are unsatisfied:
    any-of ( python_targets_python3_4 python_targets_python3_5 python_targets_python3_6 )

(dependency required by "x11-base/xorg-proto-2018.4::gentoo" [ebuild])
(dependency required by "x11-proto/presentproto-1.1-r1::gentoo" [ebuild])
(dependency required by "x11-base/xorg-server-1.19.5-r1::gentoo" [installed])
(dependency required by "@selected" [set])
(dependency required by "@world" [argument])

AND quite annoying, noting that the *installed* xorg-server version doesn't need to change,
and especially in light of the observation:

Second, as I understand this thread, both suid and nosuid are still supported in the upstream code. It is purely an omission in the Gentoo ebuild that forces you down one path.

So, which ebuild do I need to mask to work around this non-sense?

[a.m]

I doubt I'm the only one running a python2 system.

If you really run a python2 only system at this point I would say you are part of a very tiny minority.

And, I'd posit that you have no idea what you're talking about.
Can you provide a credible source or are you pulling this from a hat?

[Ant P.]

The news feature averages ~14 news items per year. I'm talking about something that notifies of trending bugs from bugzilla etc. Something actually useful.

https://bugs.gentoo.org/buglist.cgi?chf ... id=3892040
This is right on the front page of bugs.gentoo.org. Do you have special needs that this or the atom feed from a custom search doesn't provide?

[asturm]

I doubt I'm the only one running a python2 system.

If you really run a python2 only system at this point I would say you are part of a very tiny minority.

And, I'd posit that you have no idea what you're talking about.
Can you provide a credible source or are you pulling this from a hat?

May I kindly refer you to Gentoo Portage defaults.

Code: Select all

!!! The ebuild selected to satisfy ">=dev-util/meson-0.40.0" has unmet requirements.
- dev-util/meson-0.44.1::gentoo USE="" PYTHON_TARGETS="-python3_4 -python3_5 -python3_6" 

You've manually limited PYTHON_TARGETS, what do you expect? Portage tells you which packages depend on meson in this case, so you are perfectly able to defer these updates by masking them.

[a.m]

If you really run a python2 only system at this point I would say you are part of a very tiny minority.

And, I'd posit that you have no idea what you're talking about.
Can you provide a credible source or are you pulling this from a hat?

May I kindly refer you to Gentoo Portage defaults.

Right... that's what new users might use (if there were any...)

Given how low Gentoo has fallen on distrowatch (and for how long),
do you seriously think those defaults affect more actual users than
-for instance- the pre-existing installed base of gentoo for embedded
systems where python3 hasn't given a compelling reason to switch?

Code: Select all

!!! The ebuild selected to satisfy ">=dev-util/meson-0.40.0" has unmet requirements.
- dev-util/meson-0.44.1::gentoo USE="" PYTHON_TARGETS="-python3_4 -python3_5 -python3_6" 

You've manually limited PYTHON_TARGETS, what do you expect? Portage tells you which packages depend on meson in this case, so you are perfectly able to defer these updates by masking them.

I guess, I'm with the thread starter on this one. If you're going to break
my system, I'd like to know why; preferably, communicated in a news item.

The reason PYTHON_TARGETS exists is exactly to -following long-standing
gentoo tradition- let people set it as they see fit... (-;

[a.m]

Portage tells you which packages depend on meson in this case, so you are perfectly able to defer these updates by masking them.

Sure, I've done just that now; although I was naive
and got those over two dozen (!!) *-proto packages
reported one by one...

AND, I couldn't help but notice that *all* of those
were just a -rX bump of packages that used to work
just fine. Talk about reckless breakage...


Oh, and just in case this may help someone here's what
ended up in /etc/portage/package.mask/xorg-proto:

Code: Select all

=x11-proto/presentproto-1.1-r1
=x11-proto/fixesproto-5.0-r2
=x11-proto/xf86vidmodeproto-2.3.1-r2
=x11-proto/xproto-7.0.31-r1
=x11-proto/dri3proto-1.0-r1
=x11-proto/renderproto-0.11.1-r2
=x11-proto/glproto-1.4.17-r2
=x11-proto/xcmiscproto-1.2.2-r1
=x11-proto/recordproto-1.14.2-r2
=x11-proto/videoproto-2.3.3-r1
=x11-proto/resourceproto-1.2.0-r1
=x11-proto/xextproto-7.3.0-r1
=x11-proto/kbproto-1.0.7-r1
=x11-proto/randrproto-1.5.0-r1
=x11-proto/inputproto-2.3.2-r1
=x11-proto/fontsproto-2.1.3-r1
=x11-proto/scrnsaverproto-1.2.2-r2
=x11-proto/dri2proto-2.8-r2
=x11-proto/xineramaproto-1.2.1-r2
=x11-proto/xf86dgaproto-2.1-r3
=x11-proto/bigreqsproto-1.1.2-r1
=x11-proto/damageproto-1.2.1-r2
=x11-proto/compositeproto-0.4.2-r2
=x11-proto/trapproto-3.4.3-r1
=x11-proto/xf86bigfontproto-1.2.0-r2
=x11-proto/xf86driproto-2.1.1-r2

[asturm]

Right... that's what new users might use (if there were any...)

...how old is that thread in Gentoo Chat I would refer you to if I could remember? Ah, here it is.

Given how low Gentoo has fallen on distrowatch (and for how long)

Distrowatch has never been a credible source for distro usage, and much less so for Gentoo.

do you seriously think those defaults affect more actual users than
-for instance- the pre-existing installed base of gentoo

You would first have to prove that a significant amount of users is even touching PYTHON_TARGETS. For anyone who doesn't, the update just works. And for those who do manually set PYTHON_TARGETS, you would have to prove they switch to old rather than new - one thing Gentoo users are not exactly well-known for. And for anyone setting it to any python3_* target, the update also just works. Distributions are actively deprecating python2 at this point and new development is certainly not made with python2 in mind, as you can see with meson here.

I guess, I'm with the thread starter on this one. If you're going to break
my system, I'd like to know why; preferably, communicated in a news item.

But your system is not broken. Portage has told you what it needs for the upgrade to succeed. You can argue about the block message, but I find this one to be pretty clear.

The reason PYTHON_TARGETS exists is exactly to -following long-standing
gentoo tradition- let people set it as they see fit... (-;

No that is not the reason for its existence. But people can set it as they see fit within the limits imposed by the packages they install. And meson is by far not the only one requiring >=python3.

[a.m]

Right... that's what new users might use (if there were any...)

...how old is that thread in Gentoo Chat I would refer you to if I could remember? Ah, here it is.

You lost me there. Completely...
I'd appreciate if you could briefly formulate your point
instead of refering to arcane doomsday threads.

Given how low Gentoo has fallen on distrowatch (and for how long)

Distrowatch has never been a credible source for distro usage, and much less so for Gentoo.

Aha... says who?
Do you have a better / more credible source?
Please share!

do you seriously think those defaults affect more actual users than
-for instance- the pre-existing installed base of gentoo

You would first have to prove that a significant amount of users is even touching PYTHON_TARGETS. For anyone who doesn't, the update just works. And for those who do manually set PYTHON_TARGETS, you would have to prove they switch to old rather than new - one thing Gentoo users are not exactly well-known for. And for anyone setting it to any python3_* target, the update also just works. Distributions are actively deprecating python2 at this point and new development is certainly not made with python2 in mind, as you can see with meson here.

LOL... I don't *have to* prove anything. although I'm sure
I'd have a hard time if I tried. Just like you would if you tried
proving the opposite, which is more or less what my original
question regarding your source was asking you to do...

I can sympathize with your train of thought and your (to me)
unrealistic expectations, but neither of those prove anything...

I guess, I'm with the thread starter on this one. If you're going to break
my system, I'd like to know why; preferably, communicated in a news item.

But your system is not broken. Portage has told you what it needs for the upgrade to succeed. You can argue about the block message, but I find this one to be pretty clear.

I guess we have a different view on what broken is.
Yes, the info portage spits out was useful to *fix* my system,
but if it weren't broken, I wouldn't have to have spent time fixing it.

The reason PYTHON_TARGETS exists is exactly to -following long-standing
gentoo tradition- let people set it as they see fit... (-;

No that is not the reason for its existence. But people can set it as they see fit within the limits imposed by the packages they install. And meson is by far not the only one requiring >=python3.

So, enlighten me: what is the reason for the existence of PYTHON_TARGETS
(or any other similar settings) if it's not to allow choice?

[Ant P.]

Given how low Gentoo has fallen on distrowatch (and for how long)

Distrowatch has never been a credible source for distro usage, and much less so for Gentoo.

Aha... says who?
Do you have a better / more credible source?
Please share!

Why do you think a mid-90s hit counter on a third party website most likely to be visited by the sort of idiot impressed by those is a valid measure of popularity?

[a.m]

Distrowatch has never been a credible source for distro usage, and much less so for Gentoo.

Aha... says who?
Do you have a better / more credible source?
Please share!

Why do you think a mid-90s hit counter on a third party website most likely to be visited by the sort of idiot impressed by those is a valid measure of popularity?

DistroWatch had been closely tracking all the different fads (aka "popularity") over the years.
The visitor numbers have nothing to do with installed based, of course, but they do tend to
correlate well with interest, which in turn is indicative of the number of new users for a distro
(which happened to be the context of reference).


BUT, as I said, I'd be glad to learn about a more credible source.
Do you have one or were you only trying to discredit DistroWatch,
and the unsuspecting masses Google is sending their way?

[asturm]

You lost me there. Completely...
I'd appreciate if you could briefly formulate your point
instead of refering to arcane doomsday threads.

But it seems you got the gist.

Do you have a better / more credible source?
Please share!

The lack of a more credible source does not make it a credible source.

LOL... I don't *have to* prove anything. although I'm sure
I'd have a hard time if I tried. Just like you would if you tried
proving the opposite, which is more or less what my original
question regarding your source was asking you to do...

You can LOL left and right as much as you want, but disputing that python defaults in place for many years are used by anything short of the majority places the burden of proof on you. In fact, when PYTHON_TARGETS started in 2012 it was set right away with "python2_7 python3_2".

So, enlighten me: what is the reason for the existence of PYTHON_TARGETS
(or any other similar settings) if it's not to allow choice?

Similarly, we have USE=qt5 but many packages hard-depend on Qt5. We have USE=gtk but many packages hard-depend on gtk+. They allow choice where the choice is available. PYTHON_TARGETS is no different at all, except that usually more python variants need to be available at the same time for the need of compatibility, interdependence and long transition periods. That compatibility is always imposed by upstream development, and the downstream capacities to package new versions.

Btw, a very stupid grep reveals 429 python ebuilds in tree depending on >=python-3...

[a.m]

The lack of a more credible source does not make it a credible source.

I just love how you twist and bend reality. (-;

So, the original context of reference for DistroWatch was the number of *new* users.
Your first twist was to change that to distro *usage* and call DW not credible for that.
Fine, it's not. BUT, it's pretty good at tracking +popularity+ (as in interest and likely
influx as opposed to installed base).

BTW, shouldn't iso/stage3 downloads from gentoo.org give a fairly accurate view of
new installations? Are those numbers available?

... disputing that python defaults in place for many years are used by anything short of the majority places the burden of proof on you.

You know what: I never even attempted to dispute that. What I disputed, and still do,
was your statement that python2-only usage was a "very tiny minority".
That's just baseless, and very much open to interpretation.
A reasonable interpretation could be less than 1%
(and certainly less than 5%),
neither of which I believe to be accurate
(although the higher figure may not be very far off).
So, expressed in percentage, where would *you* peg that "very tiny" minority?

In fact, when PYTHON_TARGETS started in 2012 it was set right away with "python2_7 python3_2".

Right. AND, lo and behold, the first thing many of us did was to remove python3_2
to get rid of the unnecessary bloat (since running python3-only was barely viable at
that point), and -for minimal/embedded systems- python3 has not become interesting
enough to get added back... Now, if python2 does get phased out, this will change.

[Hu]

I may not be naive enough, but this is definitely noticeable:

The naive user would not have set PYTHON_TARGETS locally. As with many things, if you deviate from the default, you may sometimes need to work to stay with your deviation. In this case, the package manager did exactly what it should have done. The bad result would be if the package started to build, then died due to not having a supported Python version. Instead, you got an error message explaining what you need to change.

If you really run a python2 only system at this point I would say you are part of a very tiny minority.

And, I'd posit that you have no idea what you're talking about.
Can you provide a credible source or are you pulling this from a hat?

As a very straightforward credible source, the Gentoo default is not to do Python2 only. Users are free to change this locally, but most probably won't.

Right... that's what new users might use (if there were any...)

Not only new users. I have been a Gentoo user for a long time. Some of my systems explicitly leave PYTHON_TARGETS unset, so I get whatever is default in the tree of the day. When the Gentoo maintainers change that default, it applies to my system unless I decide to set PYTHON_TARGETS to override it. (I might do that if I want to migrate on a different schedule than the maintainers intend.) Based on your distrowatch argument, you seem to think that new users copy the Gentoo defaults into their local configuration and freeze at those values. Some people might do that, but it's not a good idea, and many seem not to do that.

I guess, I'm with the thread starter on this one. If you're going to break
my system, I'd like to know why; preferably, communicated in a news item.

I agree. Now, where is your system broken? All you've shown so far is a routine USE dependency conflict.

The reason PYTHON_TARGETS exists is exactly to -following long-standing
gentoo tradition- let people set it as they see fit... (-;

You can set it as you see fit. In this case, you have seen fit to set it to a value that prohibits installing Meson. If this is a problem for you, modify Meson to support Python2, convince someone else to do that, or find a way to avoid Meson.

[asturm]

I just love how you twist and bend reality. (-;

Why do you feel the need to emphasize your arguments with foolery like that? Maybe because you stand on loose ground?

That's just baseless, and very much open to interpretation. A reasonable interpretation could be less than 1% (and certainly less than 5%), neither of which I believe to be accurate

You believe therefore you don't know. If all you want to argue about is the real tininess of the minority then we can stop wasting our time right there.

Right. AND, lo and behold, the first thing many of us did was to remove python3_2 to get rid of the unnecessary bloat

Anecdotal evidence is anecdotal. Congratulations on making it that far without python3, but don't assume that everyone else making that decision in 2012 is doing the same thing today. And don't assume that everyone else back then was equally naive to expect this to work forever, let alone be entitled to a news item at the moment exactly their system would happen to require python3. Expect a news item by the time python2 support is dropped altogether.