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

Kevin Kofler kevin.kofler at
Mon Oct 19 00:29:40 UTC 2015

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

More information about the devel mailing list