Summary/Minutes from today's FESCo Meeting (2015-10-07)

[Kevin Kofler]

Bastien Nocera wrote:
> That's a problem for OUR users because when they use Fedora, they want to
> be able to make a tarball of their software for their friend on Ubuntu to
> test. Here, you're making Fedora a bad choice for developers that want to
> target more than just Fedora.

This already does not work even now, due to glibc. See my reply to drago01. 
(You need to compile in something like a CentOS chroot if you want binaries 
that have any chance of working cross-distro.)

>> GCC supports __attribute__((deprecated("message"))) these days. So we can
>> tag the added functions with something like:
>> __attribute__((deprecated("nonstandard function added by a non-upstream
>> patch to make FooApp work, use in other applications strongly
>> discouraged")))
>> 
>> If the developers opt to use those functions anyway, then that's not our
>> problem.
> 
> This isn't made to tag symbols that aren't upstream, and the end-user
> application will just barf out with unresolved symbols when you try to run
> it, which is far from useful.

That's the developer's fault for ignoring the warning then. There are 
already plenty of other ways to make your code intentionally non-portable 
(e.g., reading the OS version from /etc/fedora-release). What the attribute 
does is ensuring it won't happen by accident.

> I'll ask something, in earnest: have you ever written and shipped
> non-trivial software on Linux?

Yes. Which is why I know that attempting to compile cross-distro binaries on 
Fedora is a lost cause anyway.

And frankly, it really surprises me that people think that shipping a system 
library with some functions patched in is somehow worse than shipping BOTH 
an unmodified system library AND a patched library (or more) bundled with 
some application(s). Sharing code should be the prime goal, and added 
functions do not hurt anybody.

        Kevin Kofler