RFE: news item for new build dependencies

[Anon-E-moose]

[Moderator note: this post, and all posts up to and including the first post from proteusx, were originally posted in [topic=1070942][SOLVED] xorg-server-1.19.5-r1 suid use-flag removal[/topic], but were off-topic for that thread. -Hu]

I think that the worst part is that there wasn't a news item about it. I don't mind procedure changes, but I need to know about them.

They're doing the same thing with introducing meson (build system) with no warning, news, etc. Typical boorish behavior from the devs, it seems.

The only reason I mention this, is during the latest sync, I saw that python3 (which is not installed) was trying to be installed along with meson.
I had to go google to see what this latest cluster-f**k from the devs (python3/meson) is all about.

I shouldn't have to wonder what new stuff is being put on my system, that's what news articles are supposed to be for.
And I don't really want to hear, "well it was discussed on the dev's iirc" not all of us have the time or inclination to deal with that silliness.

[asturm]

Why would you need a news item about a build system? This is getting ridiculous.

[Tony0945]

Why would you need a news item about a build system? This is getting ridiculous.

Meaning, "shut up and do as you're told"?

[asturm]

"Special snowflake alert: Random new build dependencies may appear on package upgrades."

[Anon-E-moose]

do they teach that behavior at the iirc channel or is it something in the dev handbook?

[blopsalot]

meson is cool, its the future, it's so easy to do ebuilds with ninja and meson. it along with the AGILE trend, and stable git repos, the package managers are being deprecated. what went wrong here is a combination of immaturity and misuse of layman. the tree stays screwed up because it's all about what overlays you using. I've got 1083 packages and layman ain't one.

[asturm]

do they teach that behavior at the iirc channel or is it something in the dev handbook?

If you want to have news items for new build dependencies, then please apply for chief news writer. You know perfectly well you made a ridiculous statement there. And it undercuts the point you originally tried to make, however valid that might have been.

meson is just the 15th build system to attempt to replace the 14 that came before. It will probably be a lot better than scons or waf, so if only a few of those are going to switch the world will be a better place.

[blopsalot]

do they teach that behavior at the iirc channel or is it something in the dev handbook?

If you want to have news items for new build dependencies, then please apply for chief news writer. You know perfectly well you made a ridiculous statement there.

meson is just the 15th build system to attempt to replace the 14 that came before. It will probably be a lot better than scons or waf, so if only a few of those are going to switch the world will be a better place.

both gnome and Xorg are already mostly converted to meson. gnome stuff always took alot of work dealing with out of source and now that there aren't 50 proto packages, it's alot easier.

[asturm]

and now that there aren't 50 proto packages, it's alot easier.

I've heard it's also faster building that one proto package than it took to build a single one of the 10 (I think) it replaced.

[ct85711]

meson is cool, its the future, it's so easy to do ebuilds with ninja and meson. it along with the AGILE trend, and stable git repos, the package managers are being deprecated.

Didn't we hear a similar line about systemd? Yet almost everything they have said about that was proven to be incorrect; so why would meson be any different? Even if meson is an improvement, it doesn't affect what package managers job anyways; as package managers is suppose to make sure you have all the dependencies for the package, it doesn't deal with the compiling part (which is what meson and ninja is for) beyond starting the compiling sequence.

Now I will agree that the tree is a mess, especially with overlays being pushed more often as a work around (yet not actually solving the overall issue). As far as package-managers being depreciated, that won't be happening ever. As their job is hard enough with the shear amount of packages to manage and make sure everything is happy. From my experience, it is significantly harder trying to do the package manager's job yourself, especially handling new package versions and stuff. I used to do that for a couple years (before I switched to gentoo), as that was the only way you could do it if you wanted to compile packages yourself (this was way before gentoo and arch came around).

[blopsalot]

the difference is there are legitimate reasons why systemd is/was a bad idea. python 3.5 is bad now too? are you defending make/autotools or what? is cmake bad? the direct correlation is the amount of time spent on making it build reduced allowing for more time making sure it works.

here's a my bzip2 meson.build to demonstrate the simplicity, lbzip2 provides the other binaries.

Code: Select all

project('bzip2', 'c', version : '1.0.6')

bzip2_sources = [
  'blocksort.c',
  'huffman.c',
  'crctable.c',
  'randtable.c',
  'compress.c',
  'decompress.c',
  'bzlib.c'
]

libversion = meson.project_version()
soversion = '1'

bz2_c_args = ['-D_FILE_OFFSET_BITS=64']

cc = meson.get_compiler('c')
bz2_c_args += ['-Wno-unused-but-set-variable']

bz2_incs = include_directories('.')

install_headers(['bzlib.h'])

libtype = 'shared'

libbz2_shared = shared_library('bz2', bzip2_sources,
    version : libversion,
    soversion : soversion,
    c_args : bz2_c_args,
    include_directories : bz2_incs,
    install : true,
  )
  libbz2 = libbz2_shared

bz2_dep = declare_dependency(link_with : libbz2, include_directories : bz2_incs)

executable('bzcat', 'bzip2.c',
  install : true,
  dependencies : bz2_dep,
  c_args: bz2_c_args)

[Tony0945]

Well, that's certainly easier to read than an autotools makefile.

[Ant P.]

:roll: do they teach that behavior at the iirc channel or is it something in the dev handbook?

Perhaps he saw how long vapier has been acting like that without being kicked out of the project and thought it was approved behaviour?

[asturm]

That's disappointing, Ant. P.

[Hu]

I think that the worst part is that there wasn't a news item about it. I don't mind procedure changes, but I need to know about them.

They're doing the same thing with introducing meson (build system) with no warning, news, etc. Typical boorish behavior from the devs, it seems.

This is a bit different, for two reasons. First, the Xorg change that NathanZachary referenced is notable because if you previously used the +suid build (which was default, so most people did), then running emerge --oneshot x11-base/xorg-server to install the new suid-free version will leave you with a broken setup until you make the relevant permission changes. This is not a bug or oversight by the maintainers. It is a fully expected result. Since it is fully expected, and the required user intervention is well understood, it would be nice to notify users that their intervention is required.

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.

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. In contrast, upstream projects rarely maintain two fully functional build systems in parallel. If upstream chooses to use Meson, it's likely that the Gentoo maintainers must choose one of:

• Use Meson.
• Boycott new versions, pinning Gentoo on the last Meson-free version.
• Reimplement upstream build system (possibly using the last Meson-free version as a reference).

All of those options are bad. Following upstream's conversion is likely the least bad, especially when you consider limited Gentoo maintainer resources (and, in some cases, limited experience - recall that not all Gentoo maintainers have the domain expertise to take over for their respective upstreams, even if they had the time to do it).

[blopsalot]

I think that the worst part is that there wasn't a news item about it. I don't mind procedure changes, but I need to know about them.

They're doing the same thing with introducing meson (build system) with no warning, news, etc. Typical boorish behavior from the devs, it seems.

This is a bit different, for two reasons. First, the Xorg change that NathanZachary referenced is notable because if you previously used the +suid build (which was default, so most people did), then running emerge --oneshot x11-base/xorg-server to install the new suid-free version will leave you with a broken setup until you make the relevant permission changes. This is not a bug or oversight by the maintainers. It is a fully expected result. Since it is fully expected, and the required user intervention is well understood, it would be nice to notify users that their intervention is required.

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.

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. In contrast, upstream projects rarely maintain two fully functional build systems in parallel. If upstream chooses to use Meson, it's likely that the Gentoo maintainers must choose one of:

• Use Meson.
• Boycott new versions, pinning Gentoo on the last Meson-free version.
• Reimplement upstream build system (possibly using the last Meson-free version as a reference).

All of those options are bad. Following upstream's conversion is likely the least bad, especially when you consider limited Gentoo maintainer resources (and, in some cases, limited experience - recall that not all Gentoo maintainers have the domain expertise to take over for their respective upstreams, even if they had the time to do it).

yes so lets not mix up the two. it was less noticable, but the conversion of the proto packages to virtuals was fumbled as well. i am talking about base packages, I dont care if some obscure software is broken.

[asturm]

yes so lets not mix up the two. it was less noticable, but the conversion of the proto packages to virtuals was fumbled as well.

How?

[blopsalot]

x11-base/xorg-server: Fix missing revbump after dep change
Fix missing revision bump to propagate removing xf86rushproto
dependency. Otherwise, all systems with xorg-server installed can't be
upgraded to xorg-proto due to impossible blockers.

Closes: https://bugs.gentoo.org/648926

[Anon-E-moose]

I think that the worst part is that there wasn't a news item about it. I don't mind procedure changes, but I need to know about them.

They're doing the same thing with introducing meson (build system) with no warning, news, etc. Typical boorish behavior from the devs, it seems.

This is a bit different, for two reasons.

My post and point wasn't about whether they used meson or not, or it's viability.
Having did a little reading/googling, it seems to be a reasonable attempt at a build system.

It was about the lack of developer communication with the end users about pkgs, like meson, that will affect more than just a package or two.
The same thing with going -suid, a simple news release would be nice.


No, people find out about it when they go to do an emerge, and then they wonder what's going on.

If I wanted clueless devs, to control my machine, and make all the decisions as to how to use pkgs, how to compile them, etc, I'd just use redhat or some other binary distro, where it's expected that they don't care about the end users. ONE TRUE WAY doesn't work that well for a source based, build your own distro, because there is more than one way.

[/rant]

Edit to add: And I'm not really interested in some dev apologist, whining that it's too much to ask for communication from devs to end users.
It takes maybe 5 minutes to make a news post, and that's if one is a two finger typist.

[asturm]

No, your post was reeking of entitlement. emerge --ask is the tool for you to know what is going to be installed. Whatever new package you see is going to be installed, be it library or build system, is up to you to research if you so much care. You are probably the first person to demand being formally introduced to a new build dependency by news. No, portage news were not invented to babysit you through new package dependencies. Adding to Hu's remarks, there is no support whatsoever from Gentoo devs should you choose to stay on an older [out-of-tree] version of a package because you don't like a [whatever] dependency it needs. And a build system is a pretty fundamental dependency on a source-based distribution.

You clearly have no idea how the portage news process works.

[Ant P.]

No, portage news were not invented to babysit you through new package dependencies.

If it's not to alert people that a core component of their system is going to break in a backwards-incompatible way because of something that didn't come from upstream, then what use is it?

[asturm]

meson is not coming from upstream? It seems you lack some context...

[Ant P.]

Context == thread title, no?

[asturm]

Context == thread title, no?

Not since the last 15 posts or so. Was it too difficult to grasp the context out of the paragraph I wrote below Anon-E-moose?

[Ant P.]

I'm out. You're only here to win an argument.