Re: 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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Neal Gompa]

On Sun, Oct 18, 2015 at 8:17 PM, Kevin Kofler 
wrote:

> drago01 wrote:
> > They might compile something and send it to someone that happens to
> > use a different distro ...
>
> … which 99% of the time will not work anyway no matter what we do because
> glibc has only one-way compatibility and our glibc is newer than almost any
> other distro's. So trying to support that use case is not useful at all.
>
> Kevin Kofler
>
>
​While that may be true immediately upon release, it doesn't remain that
way for very long.​ Distributions like openSUSE Tumbleweed, Arch, and
distributions that release at the same time or after we do (upcoming Mageia
6, Ubuntu 15.10, etc.) would have compatibility with us.

We shouldn't make things worse for people if we don't have to.


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Kofler]

drago01 wrote:
> They might compile something and send it to someone that happens to
> use a different distro ...

… which 99% of the time will not work anyway no matter what we do because 
glibc has only one-way compatibility and our glibc is newer than almost any 
other distro's. So trying to support that use case is not useful at all.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Matthew Miller]

Hey, everyone — this thread seems to be going off the rails. Discussion
about the importance and merits of distro uniqueness is of course fine,
but please keep it technical rather than personal.

-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Petr Pisar]

On 2015-10-13, Bastien Nocera  wrote:
> We already did the "distributions aren't compatible" thing in the 90's.
>
Great. Then there is no (new) problem.

> If Ubuntu and Fedora binaries aren't compatible, which one do you think
> is going to get used by developers that need to generate programs running
> on Ubuntu?

If I need binary for A, I will use A. So simple.

-- Petr

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Bastien Nocera]

- Original Message -
> On 2015-10-13, Bastien Nocera  wrote:
> >> Bastien Nocera wrote:
> >> > 2 distributions add slightly different versions of the same
> >> > functionality
> >> > -> incompatible
> >> 
> >> I said that carrying more feature patches makes it "more likely" that
> >> packages from other distros will work, not "100% certain" (which is
> >> obviously not possible when there are incompatible versions of the same
> >> patchset floating around).
> >> 
> >> > Application compiled on Fedora using the new features -> doesn't work on
> >> > other distribution
> >> 
> >> And that's not a problem for OUR users, only for those of the other
> >> distribution. So why would that be ours to worry about?
> >
> > 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.
> >
> If you exchange Fedora and Ubuntu, you will get the same valid
> statement. This is not about Fedora or Ubuntu. It's about you don't like
> diverse world where distributions differ.

I enjoy it when people tell me what I don't like.

> I have a good news for you:
> There are different operating sytems where executing foreign blobs is
> standard practice because there is exactly one distribution of the
> operating system.

We already did the "distributions aren't compatible" thing in the 90's.

If Ubuntu and Fedora binaries aren't compatible, which one do you think
is going to get used by developers that need to generate programs running
on Ubuntu?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Petr Pisar]

On 2015-10-13, Bastien Nocera  wrote:
>> Bastien Nocera wrote:
>> > 2 distributions add slightly different versions of the same functionality
>> > -> incompatible
>> 
>> I said that carrying more feature patches makes it "more likely" that
>> packages from other distros will work, not "100% certain" (which is
>> obviously not possible when there are incompatible versions of the same
>> patchset floating around).
>> 
>> > Application compiled on Fedora using the new features -> doesn't work on
>> > other distribution
>> 
>> And that's not a problem for OUR users, only for those of the other
>> distribution. So why would that be ours to worry about?
>
> 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.
>
If you exchange Fedora and Ubuntu, you will get the same valid
statement. This is not about Fedora or Ubuntu. It's about you don't like
diverse world where distributions differ. I have a good news for you:
There are different operating sytems where executing foreign blobs is
standard practice because there is exactly one distribution of the
operating system.

-- Petr

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Bastien Nocera]

- Original Message -
> Bastien Nocera wrote:
> > 2 distributions add slightly different versions of the same functionality
> > -> incompatible
> 
> I said that carrying more feature patches makes it "more likely" that
> packages from other distros will work, not "100% certain" (which is
> obviously not possible when there are incompatible versions of the same
> patchset floating around).
> 
> > Application compiled on Fedora using the new features -> doesn't work on
> > other distribution
> 
> And that's not a problem for OUR users, only for those of the other
> distribution. So why would that be ours to worry about?

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.

> > Your advice would be making Fedora a _worse_ distribution for third-party
> > developers, and you equate those third-party developers to developers of
> > proprietary applications.
> 
> 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.

> > Not all Free Software is easy to compile from source, not all Free
> > Software is packaged in Fedora. Forcing users to become packagers before
> > they can use a third-party software is detrimental to Fedora's success.
> 
> I don't really agree, at least not fully. I think packaging software
> properly is a much more effective way to spend our time than making third-
> party blobs work as is, especially WHEN those binaries are actually Free
> Software and can thus be packaged properly from source.

Should I send you emails every time a software I want to use isn't packaged?
Because that's what it sounds like you want me to do :)

> Sure, the USERS
> should not have to become packagers, but the existing packagers should not
> waste their time on compatibility with binary blobs, but spend it usefully
> on packaging Free Software from source.

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

Because I don't think you would give those advices if you had.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[drago01]

On Mon, Oct 12, 2015 at 6:47 PM, Kevin Kofler  wrote:
> Bastien Nocera wrote:
>> 2 distributions add slightly different versions of the same functionality
>> -> incompatible
>
> I said that carrying more feature patches makes it "more likely" that
> packages from other distros will work, not "100% certain" (which is
> obviously not possible when there are incompatible versions of the same
> patchset floating around).
>
>> Application compiled on Fedora using the new features -> doesn't work on
>> other distribution
>
> And that's not a problem for OUR users, only for those of the other
> distribution. So why would that be ours to worry about?

They might compile something and send it to someone that happens to
use a different distro ...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Kofler]

Bastien Nocera wrote:
> 2 distributions add slightly different versions of the same functionality
> -> incompatible

I said that carrying more feature patches makes it "more likely" that 
packages from other distros will work, not "100% certain" (which is 
obviously not possible when there are incompatible versions of the same 
patchset floating around).

> Application compiled on Fedora using the new features -> doesn't work on
> other distribution

And that's not a problem for OUR users, only for those of the other 
distribution. So why would that be ours to worry about?

> Your advice would be making Fedora a _worse_ distribution for third-party
> developers, and you equate those third-party developers to developers of
> proprietary applications.

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.

> Not all Free Software is easy to compile from source, not all Free
> Software is packaged in Fedora. Forcing users to become packagers before
> they can use a third-party software is detrimental to Fedora's success.

I don't really agree, at least not fully. I think packaging software 
properly is a much more effective way to spend our time than making third-
party blobs work as is, especially WHEN those binaries are actually Free 
Software and can thus be packaged properly from source. Sure, the USERS 
should not have to become packagers, but the existing packagers should not 
waste their time on compatibility with binary blobs, but spend it usefully 
on packaging Free Software from source.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Kofler]

Vít Ondruch wrote:
> Precisely RPM Fusion is recently example which does not work ... Where
> are Rawhide builds? Where are the F23 builds ...

They are in the middle of an infrastructure transition and decided to not do 
any more branches on the old infrastructure, which is really an RPM Fusion 
problem and not a Fedora one.

Right now, RPM Fusion simply does not support F23 (Branched) or Rawhide. 
(This also has nothing to do with ABI changes WITHIN a release, which are 
the topic here. ABI changes from one release to the next are normal and 
expected. It is simply not realistic to expect all third-party F22 packages 
to just work on F23.) So use a released version of Fedora, those are 
supported just fine (though rebuilds for ABI changes, where needed, might 
take slightly longer than usual).

When they were using the old working infrastructure, RPM Fusion had no 
problems keeping up with Fedora, even Rawhide. Required rebuilds were 
typically pushed the same day as the Fedora change. Hopefully this will be 
the case again once the new infrastructure is finalized.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Bastien Nocera]

- Original Message -
> Bastien Nocera wrote:
> > Because adding downstream features to a system library really is the way
> > to keep ABI (not). We wouldn't even be able to use Ubuntu binaries in
> > Fedora.
> 
> As long as we only ADD features, using foreign binaries on Fedora should
> work fine. The opposite might not, but that's not OUR problem. Actually, the
> more stuff we add to our libraries, the MORE likely it is that blobs from
> other distributions (some of which already carry those patches) just work.
> 
> And in addition, personally, I don't consider cross-distribution binary
> compatibility to be a meaningful goal to begin with. Fedora is not about
> binary blobs.

2 distributions add slightly different versions of the same functionality -> 
incompatible
Application compiled on Fedora using the new features -> doesn't work on other 
distribution

Your advice would be making Fedora a _worse_ distribution for third-party 
developers, and
you equate those third-party developers to developers of proprietary 
applications.

Not all Free Software is easy to compile from source, not all Free Software is
packaged in Fedora. Forcing users to become packagers before they can use
a third-party software is detrimental to Fedora's success.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Vít Ondruch]

Dne 12.10.2015 v 17:20 Kevin Kofler napsal(a):
> Vít Ondruch wrote:
>> and we ignore the rest of the world who could build something useful on
>> the top of the Fedora.
> They just need to rebuild their stuff as well. It works fine for RPM Fusion.
>
> Kevin Kofler
>

Precisely RPM Fusion is recently example which does not work ... Where
are Rawhide builds? Where are the F23 builds ...


Vít
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Kofler]

Vít Ondruch wrote:
> and we ignore the rest of the world who could build something useful on
> the top of the Fedora.

They just need to rebuild their stuff as well. It works fine for RPM Fusion.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Kofler]

Adam Jackson wrote:
> You can compute this statically. You know the DT_NEEDED tree for every
> dynamic object.

… only if dlopen is not used (which, as I am going to explain below, is not 
anywhere near as harmless as you think).

> For applications that don't call dlopen (themselves or in their
> dependencies), that's good enough, any instance of two conflicting
> libraries in the same tree is a bug.

Sure, but most non-trivial applications do call dlopen somewhere, so this 
statement, while technically true, is entirely useless in practice.

> For callers of dlopen you also add every possible plugin they might load
> to the tree.

Every single shared library on the system is a "possible plugin they might 
load". Therefore, the result you will get is again entirely useless. (All 
applications are in the potentially conflicting set.)

And this is not purely theoretical, there are applications (and libraries) 
dlopening all sorts of system libraries, from OpenSSL to GTK+, directly (not 
through a plugin that is linked to the system library) for varying reasons.

And yes, this GTK+ example is real:
$ nm -D /usr/lib64/libQtGui.so.4 | grep Gtk
003ffee56680 T _ZN9QGtkStyle11qt_metacallEN11QMetaObject4CallEiPPv
003ffee56630 T _ZN9QGtkStyle11qt_metacastEPKc
[snip 32 lines]
003fff2d7e40 V _ZTI9QGtkStyle
003ffeec09a4 V _ZTS9QGtkStyle
003fff2d7e80 V _ZTV9QGtkStyle
so QGtkStyle is defined here, not in a plugin, but:
$ ldd /usr/lib64/libQtGui.so.4 | grep gtk
[nothing]
(This is GTK+ 2, by the way.)

An application linking both GTK+ 3 and Qt 4 will crash if and only if the 
QGtkStyle ends up getting used at runtime (which is a decision at C++ class 
level, not at file level). Good luck figuring that out with automated static 
analysis, especially on the binaries only.

> In any case you may get false positives, but you'll get no false
> negatives.

Either you get essentially the whole distribution as false positives (which 
makes the results entirely useless) or you WILL get false negatives.

> The rest of your argument reduces to "we haven't written the tool to do
> that yet", which, fair enough, but we're talking maybe 500 lines of
> python, and an optional and small amount of package metadata to trim
> the false-positive tree for dlopen.

The go ahead and write that tool. But I think you are underestimating the 
difficulty (see above).

> If you consider that scale of problem to be a "giant scary minefield" I'm
> not sure we have common grounds for communication.

The mere fact that it is possible to develop a minesweeper (which we don't 
even have yet) does not mean we are not in front of a minefield.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Kofler]

Bastien Nocera wrote:
> Because adding downstream features to a system library really is the way
> to keep ABI (not). We wouldn't even be able to use Ubuntu binaries in
> Fedora.

As long as we only ADD features, using foreign binaries on Fedora should 
work fine. The opposite might not, but that's not OUR problem. Actually, the 
more stuff we add to our libraries, the MORE likely it is that blobs from 
other distributions (some of which already carry those patches) just work.

And in addition, personally, I don't consider cross-distribution binary 
compatibility to be a meaningful goal to begin with. Fedora is not about 
binary blobs.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Adam Jackson]

On Sat, 2015-10-10 at 01:51 +0200, Kevin Kofler wrote:

> * Scanning binary packages for conflicting symbols does not work either
>   because they are only a problem if the conflicting libraries get dragged
>   into the same executable at runtime.

You can compute this statically.  You know the DT_NEEDED tree for every
dynamic object.  For applications that don't call dlopen (themselves or
in their dependencies), that's good enough, any instance of two
conflicting libraries in the same tree is a bug.  For callers of dlopen
you also add every possible plugin they might load to the tree.  In any
case you may get false positives, but you'll get no false negatives.

The rest of your argument reduces to "we haven't written the tool to do
that yet", which, fair enough, but we're talking maybe 500 lines of
python, and an optional and small amount of package metadata to trim
the false-positive tree for dlopen.  If you consider that scale of
problem to be a "giant scary minefield" I'm not sure we have common
grounds for communication.

- ajax
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Vít Ondruch]

Dne 10.10.2015 v 02:50 Kevin Kofler napsal(a):
> Chris Adams wrote:
>> Is that short-sighted?  IMHO yes.  Can Fedora fix that?  Doubtful.
>> There are three choices:
>>
>> - Fedora attempts to patch in a stable(-enough) ABI, build shared
>>   libraries, and unbundle all consumers of said libraries.  This is a
>>   large (and growing) amount of work, and there is not necessarily
>>   sufficient volunteer time to make it practical going forward.
>>
>> - Fedora excludes all such software, reducing the usefulness and
>>   relevance of Fedora to a growing number of users.
>>
>> - Fedora pushes upstreams for stable ABIs and unbundling, but recognizes
>>   the "real world" upstreams are creating, and the demands of many users
>>   who just want to have a desktop with the stuff they want to click, and
>>   so allows bundling where there's no practical alternative.
> You are missing the fourth choice: We simply push ABI-changing updates of 
> the library as grouped updates with all dependent packages

and we ignore the rest of the world who could build something useful on
the top of the Fedora.

Vít


>  This works fine 
> as long as the library is not used by too many packages and the ABI changes 
> are not so major as to require nontrivial porting. We have already done this 
> in practice many times, for several packages. For example, exiv2 updates are 
> done in such a coordinated way (usually by Rex Dieter).
>
> Kevin Kofler
>

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Bastien Nocera]

- Original Message -
> Adam Jackson wrote:
> > Bundling is _not_ intrinsically poor practice.  Firefox is a good
> > example of this,
> 
> Firefox is exactly an example of how NOT to do things, and I'm fed up of it
> getting a blanket exception to our packaging guidelines. And now the "fix"
> is to simply remove the guideline for all packages. :-(
> 
> I haven't checked recently, but last I checked, Debian unbundled a lot more
> libraries from Firefox than we did, even where upstream explicitly "did not
> allow" it. (They opted to not use the trademark anyway, so they are only
> bound by the Free Software license, that of course allows unbundling
> whatever they want.) One example is libpng, where Firefox requires the non-
> upstream APNG patch. Debian simply ripped out APNG support from Iceweasel to
> build it against the system libpng. (Though in this case, IMHO, the best fix
> would be to simply apply the APNG patch to the system libpng and ignore the
> libpng upstream's opinion. Then all browsers could benefit from APNG
> support. Some distros do that, too.)

Because adding downstream features to a system library really is the way to
keep ABI (not). We wouldn't even be able to use Ubuntu binaries in Fedora.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Vít Ondruch]

Dne 9.10.2015 v 17:46 Kevin Fenzi napsal(a):
> On Fri, 9 Oct 2015 17:05:00 +0200
> Vít Ondruch  wrote:
>
>> This does not scale unfortunately ... and it is common excuse to not
>> support it properly. IOW, I want to have package foo-1.0 installed
>> side by side with foo-2.0 and I don't want to have foo1-1.0 side by
>> side with foo-2.0. And this applies especially for packages which are
>> designed to not conflict by design.
> Of course it doesn't scale... unless someone has figured out some magic
> dust to make software bug free and always secure and always integrated,
> there needs to be people supporting all those parallel installed things
> and making sure they are secure/bugfixed/integrated. 

I am commited to maintain several versions of key ruby packages, but
there is no infrastructure in place! Let me clarify:

1) I want to maintain them in single repository.
2) I want to be able to specify upgrade path.

Non of this is supported and as long as this is not supported, I am not
willing to maintaine foo-2.0 and foo1-1.0 packages.


>
> So, the barrier is then that if you need/want a compat package, you
> must commit to maintaining it, or convince someone else to. 
>

I don't want to have compat package!


Vít


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: "Unbundling SIG" was [Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)]

[Kalev Lember]

Just replying to this one point:

On 10/11/2015 02:29 PM, Kevin Kofler wrote:
> 3. There is a common credo (which I do not adher to) in Fedora that upstream
>should be followed blindly ("upstream, upstream, upstream").

My interpretation of this is completely different than yours. :)

To me it is not at all about blindly following upstream. To me
"upstream, upstream, upstream" means that if we want to change
something in code, we should try and land our changes upstream first.
This is always not easy; sometimes it requires working with upstream and
fixing things that were discovered during code review; other times it
requires making fixes more generic than are needed for Fedora in order
to make them suitable for upstream inclusion. That all often leads to us
becoming part of upstream.

And that is a good thing, because the more involved we are with upstream
the more we are able to influence upstream so that changes that land
there work for Fedora.

I'll say it once more because it feels good to be ranting on a mailing
list. :) It is not at all about blindly following upstream. It is about
sharing the code following open source principles, and making sure we
don't effectively end up with downstream forks.

It's not easy, but it pays off in the end.

-- 
Kalev
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: "Unbundling SIG" was [Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)]

[Kevin Kofler]

Haïkel wrote:
> In short: packagers are not to be trusted, that's the bottom line of
> your argumentation.

Not at all! It is funny that you are accusing me of distrusting packagers 
when I have been arguing for years that packagers ARE to be trusted and thus 
the restrictions on updates need to go away.

What I am saying instead is that:
1. You have to acknowledge that there is an obvious conflict of interest
   between upstream and downstream on this issue.
2. Several packagers ARE upstream.
3. There is a common credo (which I do not adher to) in Fedora that upstream
   should be followed blindly ("upstream, upstream, upstream").
4. There is nothing in the new policy that states, even informally
   (= without enforcement), that unbundling is MORE IMPORTANT than following
   upstream.

And don't forget that the people who want libraries to be unbundled will in 
most cases ALSO be packagers, just not necessarily the maintainers of the 
particular package.

So there needs to be:
* a clear statement (an informal recommendation or a strict rule) that
  unbundling is the desired target state even if upstream is against it, and
* a way to deal with the potential conflicts of interest (where the packager
  is upstream and/or puts upstream's goals above ours).

I still think the old policy with its strict rule was the best way to 
address both.

If you think packagers will always do the right thing without any kind of 
guidance, then why do we have packaging guidelines at all?

> Being putting down stricter guidelines without any means of enforcing
> them, you're not solving anything.

There is a means of enforcing this guideline, just like all the other 
packaging guidelines: unsponsoring offenders! Of course, it should be done 
only as a last resort, but the possibility needs to be there.

> FESCo choose to trust contributors to do the right thing and being honest.

Then start by repealing the update stability policies.

> Wrong, it's even more "laxist" than our current one.
> https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
> https://fedoraproject.org/wiki/User:Tibbs/BundlingDraft2

It is actually not, if you read them closely.

Debian:
| Debian packages should not make use of these convenience copies unless the
| included package is explicitly intended to be used in this way.
i.e., the LIBRARY upstream decides whether it is a copylib or not. This is 
similar to the copylib exception in our old guidelines, except that they do 
not require any formal approval for copylibs.

Tibbs:
| All packages whose upstreams allow them to be built against system
| libraries must be built against system libraries.
i.e., the APPLICATION upstream decides whether it bundles its libraries or 
not. This is NOT the same thing. In most cases, they are NOT the same 
upstream, and the application upstream can bundle even libraries that DON'T 
want to be bundled.

> Besides, you're not answering the question, Matthew changed the topic
> to focus the discussion on the Unbundling SIG proposal.

I am answering some points Matthew was making, and they are within the topic 
of the thread as a whole.

> I think it's a better idea to have a focused group leading that effort
> and I hope closely with FPC.

I don't think it is fair to offload lazy packagers' work on the small group 
that cares about having Fedora done right. It is bad enough that we need to 
fix packages that are in violation of the guidelines, we should not let it 
become the norm by weakening or repealing the guidelines (but instead take 
steps to prevent this from happening to begin with).

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Kofler]

Neal Gompa wrote:
> ​Then it sounds like it would make more sense to have a mechanism to
> automatically add the user-visible version number rather than the soname.
> Though, I don't quite understand what the purpose for sonames are in the
> first place, if they aren't really designed for supporting parallel
> installable stuff...

The main reason is to efficiently detect and reject incompatible 
combinations at runtime. With RPM AutoProvides and AutoRequires, they are 
also a means to ensure a package-level dependency on the correct version of 
the library.

> ​As far as I can tell, %autosetup patch application order is controlled by
> your PatchN declarations.

Which does not (necessarily) work if you are organizing your patches by some 
other criteria. E.g., in KDE packages, we typically use 0-99 for downstream 
patches and 100+ for backported upstream patches (sometimes further broken 
down into 1xx, 2xx, 3xx, … based on the branch the patch comes from). The 
numeric ordering is not always the correct one in which to apply the 
patches.

> The other criticisms are fair, but I think %autosetup comes in handy when
> you have lots and lots of patches, and you really don't need the
> conditional application.

Actually, the more patches you have, the less likely %autosetup is to do the 
right thing. And indeed, if you have few patches, it does not help much. 
Which is why I consider %autosetup to be entirely useless.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Orion Poplawski]

On 10/09/2015 11:30 PM, Neal Gompa wrote:

Though, I don't quite understand what the purpose for sonames
are in the first place, if they aren't really designed for supporting
parallel installable stuff...


They signal a break in ABI.  Applications must be recompiled to link to 
the new version because they would not work with the new version otherwise.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: "Unbundling SIG" was [Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)]

[Haïkel]

2015-10-10 1:31 GMT+02:00 Kevin Kofler :
> Matthew Miller wrote:
>> When the packager has reasoned belief that debundling is actively bad
>> in some way for this package, I think we should trust the packager. I
>> know not everyone on this thread agrees, but in general, Fedora
>> *always* places a high level of trust in our packagers to make the
>> right call in all sorts of situations. Here, perhaps some of the
>> current (former?) pages on the rationale for unbundling could be moved
>> into the Unbundling SIG's space and used as guidance.
>
> I am worried that a lot of packagers will just refuse to do anything that
> upstream does not support, either:
> * because they ARE upstream, or
> * because they are too worried about offending upstream, or
> * because they are too lazy and/or too busy to rebase patches.
> And the often-cited fact that there are more and more upstreams not
> supporting unbundling only makes this WORSE and is actually a reason for
> MORE strictness in downstream policies, not less!
>
> The new policy does not require any kind of rationale for refusing, just
> saying "no" is enough to block everything.
>

In short: packagers are not to be trusted, that's the bottom line of
your argumentation.

Being putting down stricter guidelines without any means of enforcing
them, you're not solving anything.
FESCo choose to trust contributors to do the right thing and being honest.

>> Obviously we're not Debian, but I think this part from their Getting
>> Started guide applies to volunteer software projects in general:
>>
>> * We all are volunteers.
>>  * You cannot impose on others what to do.
>>  * You should be motivated to do things by yourself.
>>
>> 
>
> I find it funny that you are citing Debian in an attempt to support your
> point, because Debian actually has a "no bundled libraries" policy at least
> as strict as our old one.
>
> Kevin Kofler
>

Wrong, it's even more "laxist" than our current one.
https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
https://fedoraproject.org/wiki/User:Tibbs/BundlingDraft2

You know the difference? Debian trusts maintainers to do the right
thing by default.
If we can't trust Fedora maintainers, then we have another problem to solve.

Besides, you're not answering the question, Matthew changed the topic
to focus the discussion on the Unbundling SIG proposal.
I think it's a better idea to have a focused group leading that effort
and I hope closely with FPC.

I envision their mission being:
* work on detecting bundled libraries in the current packages collection
* work with package maintainers and upstream developers to reduce bundling.
* document
* cooperate with FPC to apply best practices
* cooperate with security team when CVE is discovered in a bundled lib
(filing tickets or apply fix as provenpackagers)
* provides metrics to follow the progress of that effort.

If you care about reducing bundling, this is a far more effective
solution than stricter guidelines.

Regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Alec Leamas]

On 09/10/15 21:13, Stephen Gallagher wrote:

> I completely, wholeheartedly agree with you here. However, the
> unfortunate fact of life is that we can lead a horse to water but
> cannot make them drink. Our previous policy was essentially holding
> the horse's head under the water until it drained the pond or drowned
> in it. I feel we can do better by being more moderate. The Unbundling
> SIG mentioned elsewhere in this thread is probably a more productive
> approach.

First, I generally agree that leaving the final decision to the packager
under the kind of umbrella proposed is the right thing to do.

That said, question is if we are leading the horse to the water? IMHO,
the proposed rules is more like pointing out the general direction to
the water for the poor horse (that's me, a mere mortal packager).

Perhaps Kevin K has a point in that these rules doesn't even require a
motivation from the packager when bundling. What if we required some
kind of process, still leaving the final decision to the packager? E.
g., requiring that all bundling should be at least reported to the FPC,
with a revised set of standard questions dealt with? Perhaps requiring
that FPC (or some other body) should be given the chance to give some
piece of advice before the bundled package is committed?

Whatever. But if we take bundling seriously, why not require some kind
of process? Not so complicated that it's simply avoided (as often
today), but still something which makes a packager think twice?


Cheers!

--alec

PS Sorry for not being able to match Stephens horse-drowning metaphor :) DS
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Neal Gompa]

On Fri, Oct 9, 2015 at 9:32 PM, Kevin Kofler  wrote:

> Neal Gompa wrote:
> > ​At this point in time, Fedora is the only major distribution I know of
> > that doesn't use versioned shared library package names. Both SUSE and
> > Mageia do, and of course the Debian/Ubuntu family does. I've spoken to
> > folks working in both SUSE and Mageia (especially Mageia as of late), and
> > I've heard that there's a particular eagerness to find a way to have RPM
> > generate these versioned library names for packages.
>
> Debian has to use it because dpkg does not support soname dependencies. But
> for RPM-based distributions, it just does not make sense. The only thing it
> allows (that the soname AutoProvides and AutoRequires don't already handle)
> is to attempt to parallel-install libraries for which this is NOT
> supported,
> which is a recipe for:
> 1. security issues, because you are using an obsolete unmaintained library
>version without realizing it (because nothing will replace your libfoo1
>if the current version of your distribution ships libfoo2 instead), and
> 2. file conflicts, because nobody tested parallel installation of the 2
>versions.
>
> IMHO, shipping a compatibility library needs to be a concious decision by a
> maintainer. A naming scheme that allows abusing old unmaintained packages
> as
> compatibility packages is a recipe for a disaster.
>
> > Mageia itself has a macro that generates these names, and packagers
> merely
> > have to utilize them to get the appropriate name generation. Part of that
> > is because of the quirks of urpmi and supporting multilib, but I don't
> see
> > why we couldn't work with the other two distros to develop a standardized
> > soname suffix generator that could simply be activated as a flag on a
> > subpackage.
>
> The Mageia soversion macros are a horrible overengineered mess that leads
> to
> unreadable and overcomplicated spec files. Please do NOT pollute Fedora
> packages with such completely unnecessary macros.
>
> I also think our naming scheme for libraries makes a lot more sense:
> 1. The default version of the library typically has NO version suffix.
> Thus:
>1.1. It is obvious to users which version is the default.
>1.2. The package names for the default version are simpler.
>

​That's a fair point.


> 2. Compatibility libraries are normally named after the user-visible
>version, NOT the soversion. E.g., if we ship libfoo 0.10 as a
>compatibility library, we ship it as libfoo010, not something like
>libfoo7. Soversion-based naming is particularly misleading for kdelibs,
>where kdelibs 3 has the soversion 4 and kdelibs 4 has the soversion 5.
>(The new KDE Frameworks 5 now typically also have 5 as their soversion,
>the libraries have new names (libKF5*.so) so they don't conflict. But as
>long as older kdelibs still exist, that just adds to the confusion.) Our
>kdelibs 3 package is called kdelibs3, not kdelibs4, which would be
>extremely misleading. Debian used kdelibs4c2a for kdelibs 3 and kdelibs5
>for kdelibs 4! (The "c2a" is another unreadable mess because they
> decided
>to encode the C++ ABI in the package name. We just did a mass rebuild on
>a flag day and were done with it.)
>

​Then it sounds like it would make more sense to have a mechanism to
automatically add the user-visible version number rather than the soname.
Though, I don't quite understand what the purpose for sonames are in the
first place, if they aren't really designed for supporting parallel
installable stuff...



> 3. There is also no requirement that library package names start with
>"lib*". This should also stay that way. E.g., upstream thinks of glib as
>glib, not libglib (a particularly silly name, by the way). So we should
>not unnecessarily munge the name.
>
>
​I don't want to have to unnecessarily munge the name either. For a similar
reason, I don't like the lib/lib64 prefix naming they have to do in order
to work around weaknesses in some of their tooling.​



> > ​IMO, it would be very nice if we could come together and hash out a
> > standardized approach to things. We've done it with %autosetup,
> > %autopatch, %make_build / %make_install, and a number of other things in
> > RPM, I don't see why we can't for this too.
>
> %autosetup is an inflexible nonsense that just does not work in many setups
> (no control over the application order of the patches, no control over the
> switches passed to patch, no way to conditionally apply patches, etc.), and
> also does not help specfile readability. I refuse to use %autosetup in my
> packages and will yell at anybody that dares changing one of my packages to
> use it (and revert the commit).
>
>
​As far as I can tell, %autosetup patch application order is controlled by
your PatchN declarations. I've not seen a circumstance where it works
differently. But that's besides the point. The point I was trying to make
is that we should move towards implemen

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

[Kevin Kofler]

Neal Gompa wrote:
> ​At this point in time, Fedora is the only major distribution I know of
> that doesn't use versioned shared library package names. Both SUSE and
> Mageia do, and of course the Debian/Ubuntu family does. I've spoken to
> folks working in both SUSE and Mageia (especially Mageia as of late), and
> I've heard that there's a particular eagerness to find a way to have RPM
> generate these versioned library names for packages.

Debian has to use it because dpkg does not support soname dependencies. But 
for RPM-based distributions, it just does not make sense. The only thing it 
allows (that the soname AutoProvides and AutoRequires don't already handle) 
is to attempt to parallel-install libraries for which this is NOT supported, 
which is a recipe for:
1. security issues, because you are using an obsolete unmaintained library
   version without realizing it (because nothing will replace your libfoo1
   if the current version of your distribution ships libfoo2 instead), and
2. file conflicts, because nobody tested parallel installation of the 2
   versions.

IMHO, shipping a compatibility library needs to be a concious decision by a 
maintainer. A naming scheme that allows abusing old unmaintained packages as 
compatibility packages is a recipe for a disaster.

> Mageia itself has a macro that generates these names, and packagers merely
> have to utilize them to get the appropriate name generation. Part of that
> is because of the quirks of urpmi and supporting multilib, but I don't see
> why we couldn't work with the other two distros to develop a standardized
> soname suffix generator that could simply be activated as a flag on a
> subpackage.

The Mageia soversion macros are a horrible overengineered mess that leads to 
unreadable and overcomplicated spec files. Please do NOT pollute Fedora 
packages with such completely unnecessary macros.

I also think our naming scheme for libraries makes a lot more sense:
1. The default version of the library typically has NO version suffix. Thus:
   1.1. It is obvious to users which version is the default.
   1.2. The package names for the default version are simpler.
2. Compatibility libraries are normally named after the user-visible
   version, NOT the soversion. E.g., if we ship libfoo 0.10 as a
   compatibility library, we ship it as libfoo010, not something like
   libfoo7. Soversion-based naming is particularly misleading for kdelibs,
   where kdelibs 3 has the soversion 4 and kdelibs 4 has the soversion 5.
   (The new KDE Frameworks 5 now typically also have 5 as their soversion,
   the libraries have new names (libKF5*.so) so they don't conflict. But as
   long as older kdelibs still exist, that just adds to the confusion.) Our
   kdelibs 3 package is called kdelibs3, not kdelibs4, which would be
   extremely misleading. Debian used kdelibs4c2a for kdelibs 3 and kdelibs5
   for kdelibs 4! (The "c2a" is another unreadable mess because they decided
   to encode the C++ ABI in the package name. We just did a mass rebuild on
   a flag day and were done with it.)
3. There is also no requirement that library package names start with
   "lib*". This should also stay that way. E.g., upstream thinks of glib as
   glib, not libglib (a particularly silly name, by the way). So we should
   not unnecessarily munge the name.

> ​IMO, it would be very nice if we could come together and hash out a
> standardized approach to things. We've done it with %autosetup,
> %autopatch, %make_build / %make_install, and a number of other things in
> RPM, I don't see why we can't for this too.

%autosetup is an inflexible nonsense that just does not work in many setups 
(no control over the application order of the patches, no control over the 
switches passed to patch, no way to conditionally apply patches, etc.), and 
also does not help specfile readability. I refuse to use %autosetup in my 
packages and will yell at anybody that dares changing one of my packages to 
use it (and revert the commit).

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Kofler]

Adam Jackson wrote:
> Bundling is _not_ intrinsically poor practice.  Firefox is a good
> example of this,

Firefox is exactly an example of how NOT to do things, and I'm fed up of it 
getting a blanket exception to our packaging guidelines. And now the "fix" 
is to simply remove the guideline for all packages. :-(

I haven't checked recently, but last I checked, Debian unbundled a lot more 
libraries from Firefox than we did, even where upstream explicitly "did not 
allow" it. (They opted to not use the trademark anyway, so they are only 
bound by the Free Software license, that of course allows unbundling 
whatever they want.) One example is libpng, where Firefox requires the non-
upstream APNG patch. Debian simply ripped out APNG support from Iceweasel to 
build it against the system libpng. (Though in this case, IMHO, the best fix 
would be to simply apply the APNG patch to the system libpng and ignore the 
libpng upstream's opinion. Then all browsers could benefit from APNG 
support. Some distros do that, too.)

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Kofler]

Chris Adams wrote:
> Is that short-sighted?  IMHO yes.  Can Fedora fix that?  Doubtful.
> There are three choices:
> 
> - Fedora attempts to patch in a stable(-enough) ABI, build shared
>   libraries, and unbundle all consumers of said libraries.  This is a
>   large (and growing) amount of work, and there is not necessarily
>   sufficient volunteer time to make it practical going forward.
> 
> - Fedora excludes all such software, reducing the usefulness and
>   relevance of Fedora to a growing number of users.
> 
> - Fedora pushes upstreams for stable ABIs and unbundling, but recognizes
>   the "real world" upstreams are creating, and the demands of many users
>   who just want to have a desktop with the stuff they want to click, and
>   so allows bundling where there's no practical alternative.

You are missing the fourth choice: We simply push ABI-changing updates of 
the library as grouped updates with all dependent packages. This works fine 
as long as the library is not used by too many packages and the ABI changes 
are not so major as to require nontrivial porting. We have already done this 
in practice many times, for several packages. For example, exiv2 updates are 
done in such a coordinated way (usually by Rex Dieter).

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Kofler]

Zdenek Kabelac wrote:
> IMHO  all we need is to support  multiple version of same library
> to be installable  -- that's mine point why  usability of Fedora
> is miles behind other distros.

Then you open the doors to symbol conflicts (see my reply to Adam Jackson 
elsewhere in this thread).

And the Debian way that just lets you keep your libfoo1 from even an older 
RELEASE of Debian, with no updates whatsoever, not even security updates 
(because there is simply no libfoo1 in the repositories for the current 
version if the libfoo source package now produces libfoo2 instead), does not 
work either. Compatibility packages MUST be maintained or they become a 
major security issue.

The compatibility libraries also partly defeat the space savings that can be 
had from unbundling.

Compatibility libraries must only be a last resort, if it is really not 
possible to port the packages to the latest version. By default, we ALWAYS 
need to port to the latest version.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Neal Gompa]

On Fri, Oct 9, 2015 at 4:47 PM, Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Fri, Oct 09, 2015 at 11:38:30AM -0600, Orion Poplawski wrote:
> > On 10/09/2015 10:27 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Fri, Oct 09, 2015 at 09:46:11AM -0600, Kevin Fenzi wrote:
> > >> On Fri, 9 Oct 2015 17:05:00 +0200
> > >> Vít Ondruch  wrote:
> > >>
> > >>> This does not scale unfortunately ... and it is common excuse to not
> > >>> support it properly. IOW, I want to have package foo-1.0 installed
> > >>> side by side with foo-2.0 and I don't want to have foo1-1.0 side by
> > >>> side with foo-2.0. And this applies especially for packages which are
> > >>> designed to not conflict by design.
> > >>
> > >> Of course it doesn't scale... unless someone has figured out some
> magic
> > >> dust to make software bug free and always secure and always
> integrated,
> > >> there needs to be people supporting all those parallel installed
> things
> > >> and making sure they are secure/bugfixed/integrated.
> > >>
> > >> So, the barrier is then that if you need/want a compat package, you
> > >> must commit to maintaining it, or convince someone else to.
> > >
> > > Debian seems to have solved this problem in a much nicer way: multiple
> > > major versions of shared libraries can be installed in parallel, and
> > > manual work is not required, the version of the library is included
> > > in the binary package name.
> >
> > When you say that no manual work is required, for whom do you mean?  Is
> the
> > packaging handled automatically as well?
> Depends what you mean by automatically: debian packaging requires
> lots of manual steps. In case of an so bump the version string has to
> be updated in various places in the debian/control file. I presume
> that most people do search&replace on the file.
>
>
​At this point in time, Fedora is the only major distribution I know of
that doesn't use versioned shared library package names. Both SUSE and
Mageia do, and of course the Debian/Ubuntu family does. I've spoken to
folks working in both SUSE and Mageia (especially Mageia as of late), and
I've heard that there's a particular eagerness to find a way to have RPM
generate these versioned library names for packages.

Mageia itself has a macro that generates these names, and packagers merely
have to utilize them to get the appropriate name generation. Part of that
is because of the quirks of urpmi and supporting multilib, but I don't see
why we couldn't work with the other two distros to develop a standardized
soname suffix generator that could simply be activated as a flag on a
subpackage.

​IMO, it would be very nice if we could come together and hash out a
standardized approach to things. We've done it with %autosetup, %autopatch,
%make_build / %make_install, and a number of other things in RPM, I don't
see why we can't for this too.

-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Kofler]

Adam Jackson wrote:
> I'd call that the app not working, yes.  Symbol conflicts are literally
> trivial to find, I'm really not sure why you bring the point up.

Because it is the worst possible consequence of bundled libraries (or abuse 
of compatibility libraries – there too, more effort needs to be spent on 
making things work with the latest version of the library, a compatibility 
library must be only a last resort).

And symbol conflicts are not that trivial to detect:
* The packages will typically build just "fine", the crashes happen only at
  runtime.
* Scanning binary packages for conflicting symbols does not work either
  because they are only a problem if the conflicting libraries get dragged
  into the same executable at runtime.
* The crashes can appear only if or when certain plugins are loaded.
  (Plugins are an additional obstacle for any kind of static analysis.)
* The crashes can appear only on certain desktop environments, because a
  conflicting library can get dragged in by platform integration plugins.
* The crashes can even appear only on certain hardware! One example from the
  past: The dreaded Krita symbol conflict between OpenGTL and Mesa OpenGL
  (which both bundled their own, incompatible copies of LLVM). Krita was
  working fine (or at least without crashing on this symbol conflict) on
  proprietary drivers, but not on the Free ones. (This was originally fixed
  in Fedora and distributions that listened to my advice in the upstream bug
  by making both OpenGTL and Mesa link to the same shared LLVM library. But
  some distributions kept using bundled, static or compatibility copies of
  the LLVM library and thus that crash still existed on some distributions
  years later! It is now historical because OpenGTL was discontinued and
  Krita stopped using it.) This example, by the way, is why I am extremely
  worried about the recent explosion of llvm* compatibility libraries in
  Fedora.
* A symbol conflict that happens not to cause a crash can suddenly start
  crashing if the implementation of one of the 2 versions of the library
  changes.

So to me, this is a giant scary mine field that is just waiting for somebody 
to step on it. And I get the feeling that the vast majority of our packagers 
does not understand the risk.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: "Unbundling SIG" was [Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)]

[Kevin Kofler]

Matthew Miller wrote:
> When the packager has reasoned belief that debundling is actively bad
> in some way for this package, I think we should trust the packager. I
> know not everyone on this thread agrees, but in general, Fedora
> *always* places a high level of trust in our packagers to make the
> right call in all sorts of situations. Here, perhaps some of the
> current (former?) pages on the rationale for unbundling could be moved
> into the Unbundling SIG's space and used as guidance.

I am worried that a lot of packagers will just refuse to do anything that
upstream does not support, either:
* because they ARE upstream, or
* because they are too worried about offending upstream, or
* because they are too lazy and/or too busy to rebase patches.
And the often-cited fact that there are more and more upstreams not
supporting unbundling only makes this WORSE and is actually a reason for
MORE strictness in downstream policies, not less!

The new policy does not require any kind of rationale for refusing, just
saying "no" is enough to block everything.

> Obviously we're not Debian, but I think this part from their Getting
> Started guide applies to volunteer software projects in general:
> 
> * We all are volunteers.
>  * You cannot impose on others what to do.
>  * You should be motivated to do things by yourself.
> 
> 

I find it funny that you are citing Debian in an attempt to support your
point, because Debian actually has a "no bundled libraries" policy at least
as strict as our old one.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Zbigniew Jędrzejewski-Szmek]

On Fri, Oct 09, 2015 at 11:38:30AM -0600, Orion Poplawski wrote:
> On 10/09/2015 10:27 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Oct 09, 2015 at 09:46:11AM -0600, Kevin Fenzi wrote:
> >> On Fri, 9 Oct 2015 17:05:00 +0200
> >> Vít Ondruch  wrote:
> >>
> >>> This does not scale unfortunately ... and it is common excuse to not
> >>> support it properly. IOW, I want to have package foo-1.0 installed
> >>> side by side with foo-2.0 and I don't want to have foo1-1.0 side by
> >>> side with foo-2.0. And this applies especially for packages which are
> >>> designed to not conflict by design.
> >>
> >> Of course it doesn't scale... unless someone has figured out some magic
> >> dust to make software bug free and always secure and always integrated,
> >> there needs to be people supporting all those parallel installed things
> >> and making sure they are secure/bugfixed/integrated. 
> >>
> >> So, the barrier is then that if you need/want a compat package, you
> >> must commit to maintaining it, or convince someone else to. 
> > 
> > Debian seems to have solved this problem in a much nicer way: multiple
> > major versions of shared libraries can be installed in parallel, and
> > manual work is not required, the version of the library is included
> > in the binary package name.
> 
> When you say that no manual work is required, for whom do you mean?  Is the
> packaging handled automatically as well?
Depends what you mean by automatically: debian packaging requires
lots of manual steps. In case of an so bump the version string has to
be updated in various places in the debian/control file. I presume
that most people do search&replace on the file.

> > Fedora sets this bar very high: a separate review, slightly different
> > guidelines, so nobody bothers except for special cases.
>
> I suspect the case brought up by Adam wouldn't be helped by this - as I expect
> it wouldn't have been a major version update to cairo.  Even minor updates can
> trigger issues, and supporting parallel installation of the same sonames I
> could image would be very tricky.

Yeah, sounds like it wouldn't help in this case.

Zbyszek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Matthew Miller]

On Fri, Oct 09, 2015 at 08:04:39PM +0100, Richard W.M. Jones wrote:
> This doesn't have to be.  It is possible to write libraries, even very
> complex ones, with endless backwards compatibility.  It's what libvirt
> does.  And the kernel (almost always).
> 
> In fact I'd say breaking your ABI contract continuously is another
> lazy, poor programming practice.

We just plain don't have the clout to use inclusion in Fedora as a
lever to fix this. And I don't see the benefit to Fedora in excluding
software which uses them from the Fedora universe. I mean, if we
insisted on perfection, the distribution would consist solely of
software written personally by Donald Knuth.

-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/09/2015 03:04 PM, Richard W.M. Jones wrote:
> On Fri, Oct 09, 2015 at 04:36:37PM +0200, Zdenek Kabelac wrote:
>> But in the real-world - version changes, it gets incompatible, 
>> requires some new way how to use it and so on
> 
> This doesn't have to be.  It is possible to write libraries, even
> very complex ones, with endless backwards compatibility.  It's what
> libvirt does.  And the kernel (almost always).
> 
> In fact I'd say breaking your ABI contract continuously is another 
> lazy, poor programming practice.

I completely, wholeheartedly agree with you here. However, the
unfortunate fact of life is that we can lead a horse to water but
cannot make them drink. Our previous policy was essentially holding
the horse's head under the water until it drained the pond or drowned
in it. I feel we can do better by being more moderate. The Unbundling
SIG mentioned elsewhere in this thread is probably a more productive
approach.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlYYEcUACgkQeiVVYja6o6NfZwCeJmqJ4xF6ZhWovvdgdLpDUfZS
xKgAoInJ1v8eYnJcvo9pAelEdxI4QBG4
=ex3I
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Chris Adams]

Once upon a time, Richard W.M. Jones  said:
> On Fri, Oct 09, 2015 at 04:36:37PM +0200, Zdenek Kabelac wrote:
> > But in the real-world - version changes, it gets incompatible,
> > requires some new way how to use it and so on
> 
> This doesn't have to be.  It is possible to write libraries, even very
> complex ones, with endless backwards compatibility.  It's what libvirt
> does.  And the kernel (almost always).
> 
> In fact I'd say breaking your ABI contract continuously is another
> lazy, poor programming practice.

That's nice to say, but there are a number of upstreams that do so
semi-regularly.  And, there are upstreams that don't claim any ABI and
encourage their consumers (other upstream projects) to bundle their
products.  Are you willing to take over leadership of every such project
to show them better practices?

Is that short-sighted?  IMHO yes.  Can Fedora fix that?  Doubtful.
There are three choices:

- Fedora attempts to patch in a stable(-enough) ABI, build shared
  libraries, and unbundle all consumers of said libraries.  This is a
  large (and growing) amount of work, and there is not necessarily
  sufficient volunteer time to make it practical going forward.

- Fedora excludes all such software, reducing the usefulness and
  relevance of Fedora to a growing number of users.

- Fedora pushes upstreams for stable ABIs and unbundling, but recognizes
  the "real world" upstreams are creating, and the demands of many users
  who just want to have a desktop with the stuff they want to click, and
  so allows bundling where there's no practical alternative.

-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Richard W.M. Jones]

On Fri, Oct 09, 2015 at 04:36:37PM +0200, Zdenek Kabelac wrote:
> But in the real-world - version changes, it gets incompatible,
> requires some new way how to use it and so on

This doesn't have to be.  It is possible to write libraries, even very
complex ones, with endless backwards compatibility.  It's what libvirt
does.  And the kernel (almost always).

In fact I'd say breaking your ABI contract continuously is another
lazy, poor programming practice.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Orion Poplawski]

On 10/09/2015 10:27 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Oct 09, 2015 at 09:46:11AM -0600, Kevin Fenzi wrote:
>> On Fri, 9 Oct 2015 17:05:00 +0200
>> Vít Ondruch  wrote:
>>
>>> This does not scale unfortunately ... and it is common excuse to not
>>> support it properly. IOW, I want to have package foo-1.0 installed
>>> side by side with foo-2.0 and I don't want to have foo1-1.0 side by
>>> side with foo-2.0. And this applies especially for packages which are
>>> designed to not conflict by design.
>>
>> Of course it doesn't scale... unless someone has figured out some magic
>> dust to make software bug free and always secure and always integrated,
>> there needs to be people supporting all those parallel installed things
>> and making sure they are secure/bugfixed/integrated. 
>>
>> So, the barrier is then that if you need/want a compat package, you
>> must commit to maintaining it, or convince someone else to. 
> 
> Debian seems to have solved this problem in a much nicer way: multiple
> major versions of shared libraries can be installed in parallel, and
> manual work is not required, the version of the library is included
> in the binary package name.

When you say that no manual work is required, for whom do you mean?  Is the
packaging handled automatically as well?

> Fedora sets this bar very high: a separate review, slightly different
> guidelines, so nobody bothers except for special cases.
> 
> Zbyszek
> 

I suspect the case brought up by Adam wouldn't be helped by this - as I expect
it wouldn't have been a major version update to cairo.  Even minor updates can
trigger issues, and supporting parallel installation of the same sonames I
could image would be very tricky.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Orion Poplawski]

On 10/09/2015 08:16 AM, Adam Jackson wrote:
> Reality is complicated, we would do well to recognize that.
> 
> - ajax
> 

Thank you very much for the excellent posts.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

"Unbundling SIG" was [Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)]

[Matthew Miller]

On Fri, Oct 09, 2015 at 11:00:30AM -0400, Stephen Gallagher wrote:
> > +1 And I was serious about it, rather sticking to guidelines as if
> > they were dogma, I prefer positive actions to fight poor
> > practices.
> I'm thoroughly behind this. I think an unbundling SIG is a far better
> solution to the bundling problem than the high barrier-to-entry and
> poor-enforcement solution that we had previously.
> Having a group of motivated and knowledgeable individuals focused on
> removing unnecessary bundling would be far more likely to result in
> secure *and* usable software. I'd be more than happy to participate in
> such a SIG as time allows.

One of Kevin's concerns — I think I can state fairly! — is that the
previous policy had basically the strongest teeth we have for anything
in Fedora. If you don't debundle, you can't participate.

I think we should generally trust the package maintainers to make the
right call on whether debundling would be _actively problematic_ for
their package. But, going back to my triangle illustration:

A. For packagers with inclination and availability, but short on
expertise, the Unbundling SIG will be clearly valuable. The SIG could
offer patches both initially and when needed on an ongoing basis.
(Possibly the policy would be for someone from the SIG to become a
comaintainer, or possibly even use provenpackager privs for this
purpose with coordination with the package's primary contact.)

B. For packagers with inclination and expertise, but no *time*, pretty
much the same deal.

C. Now, when we get to availablity and expertise but no inclination
well, let me break that down further.

When the packager has reasoned belief that debundling is actively bad
in some way for this package, I think we should trust the packager. I
know not everyone on this thread agrees, but in general, Fedora
*always* places a high level of trust in our packagers to make the
right call in all sorts of situations. Here, perhaps some of the
current (former?) pages on the rationale for unbundling could be moved
into the Unbundling SIG's space and used as guidance.

But, in the case where the packager just doesn't see it as important,
maybe the Unbundling SIG could have a stronger mandate, possibly
overseen by the FPC, to also sign up for comaintainership and make the
necessary packaging changes.

In cases where the bundled libraries already exist in Fedora, this
might be as simple as changing the "packages whose upstreams allow them
to be built against system libraries must be built against system
libraries" to "packages which can be correctly built against libraries
already packaged separately in Fedora must use those libraries, or get
an exception from the FPC".
   
If the bundled libraries *don't* already exist separately in Fedora,
the previous policy required the would-be packager to do what is often
a huge amount of work to separate them, and in many cases, that was for
very, very little actual gain, as these then just became new leaves
with only one consumer. I'm not very excited about policies which
demand that other people do work — not necessarily as a matter of
libertarian principles, but just as practicality. Obviously we're not
Debian, but I think this part from their Getting Started guide applies
to volunteer software projects in general:

* We all are volunteers.
 * You cannot impose on others what to do.
 * You should be motivated to do things by yourself.



and in that light, I think if there's something which isn't previously
available but *could* be, and which the Unbundling SIG indentifies as
important, the Unbundling SIG could work to make those libs available
independently, turning this into the previous case.


I'd also like to see something like:

   When adding a package which carries a bundled library, the name
   chosen in "Provides: bundled()" should match the naming
   guidelines as if that package were provided separately. When in
   doubt, check with the FPC.

   When adding this line, please run [whatever command] to find
   existing packages which provide that library, and consider
   contacting the maintainers of those packages and the Unbundling SIG
   to work on an effort to make this into a separate, shared package.
   See [Why Bundled Libraries Are Bad] for details on how this benefits
   Fedora maintainers and users.



-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Zbigniew Jędrzejewski-Szmek]

On Fri, Oct 09, 2015 at 09:46:11AM -0600, Kevin Fenzi wrote:
> On Fri, 9 Oct 2015 17:05:00 +0200
> Vít Ondruch  wrote:
> 
> > This does not scale unfortunately ... and it is common excuse to not
> > support it properly. IOW, I want to have package foo-1.0 installed
> > side by side with foo-2.0 and I don't want to have foo1-1.0 side by
> > side with foo-2.0. And this applies especially for packages which are
> > designed to not conflict by design.
> 
> Of course it doesn't scale... unless someone has figured out some magic
> dust to make software bug free and always secure and always integrated,
> there needs to be people supporting all those parallel installed things
> and making sure they are secure/bugfixed/integrated. 
> 
> So, the barrier is then that if you need/want a compat package, you
> must commit to maintaining it, or convince someone else to. 

Debian seems to have solved this problem in a much nicer way: multiple
major versions of shared libraries can be installed in parallel, and
manual work is not required, the version of the library is included
in the binary package name.

Fedora sets this bar very high: a separate review, slightly different
guidelines, so nobody bothers except for special cases.

Zbyszek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Adam Jackson]

On Fri, 2015-10-09 at 14:55 +, Jóhann B. Guðmundsson wrote:

> Interesting taking the consumer perspective.
> 
> So where does FESCo intend to draw the line now that it has chosen to 
> head down this path.

I mean, I can't speak for fesco as a whole, but speaking for myself: I
reject the question.  I don't think "drawing a line" is a useful way to
think about these issues.  All engineering is compromise.

> For example is the next step for Fedora to dissociate itself with 
> upstream and start implementing "workarounds" instead of fixing things 
> where they belong to satisfy the end users needs and expectation as well?

I'm not sure if you're aware, but that is exactly the thing a
distribution is.  The software we package is not produced with a single
vision in mind, it does not all just magically fit together on the
first try.  From a quick grep, of the 16000ish packages in rawhide,
~5500 have at least one patch in their spec file, and there are about
18000 patches total.  Frankly I'm pleased it's that low.

You appear to be trying to set up a false dichotomy, and I reject that
model.  Of course we're going to continue to work with upstreams on
bugs and best practices.  It won't always be successful, it never has
been and it never will be, and we will always carry patches to make
Fedora work.  We will continue to work to reduce that delta, even
though we know that it will never be zero.

More to the point, any internal beauty and elegance in building the OS
itself is fundamentally uninteresting.  They are fine goals to have,
but they are only _good_ in proportion to the quality of system they
build, and the ultimate measure of quality here is utility.  If that
means I need two forks of a library in the OS because different apps
have incommensurate needs and uses of that library, so be it.

Like I said, reality is complicated.  Maybe it's unfortunate that
reality doesn't conform to our expectations, but as far as I can tell
that's been true for literally my entire life so I kinda stopped being
surprised and upset by that.

- ajax
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Fenzi]

On Fri, 9 Oct 2015 17:22:34 +0200
Zdenek Kabelac  wrote:

> If all it would take would be e.g. : dnf  install-compat
> 
> Otherwise you basically require  that every user of Fedora is
> supposedly quite skilled rpm package-maintainer ??
> (Which would roughly cut the user-base  only to those who actively
> maintain package in Fedora)

Well, someone has to maintain the packages... I don't think it's
practical at this point to automate that all away. 

Users who aren't maintainers would need to convince some maintainer to
take on the work. 

kevin


pgpFexp3ThOkP.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Fenzi]

On Fri, 9 Oct 2015 17:05:00 +0200
Vít Ondruch  wrote:

> This does not scale unfortunately ... and it is common excuse to not
> support it properly. IOW, I want to have package foo-1.0 installed
> side by side with foo-2.0 and I don't want to have foo1-1.0 side by
> side with foo-2.0. And this applies especially for packages which are
> designed to not conflict by design.

Of course it doesn't scale... unless someone has figured out some magic
dust to make software bug free and always secure and always integrated,
there needs to be people supporting all those parallel installed things
and making sure they are secure/bugfixed/integrated. 

So, the barrier is then that if you need/want a compat package, you
must commit to maintaining it, or convince someone else to. 

kevin



pgpxOu7_A5n2q.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Peter Jones]

On Fri, Oct 09, 2015 at 10:16:31AM -0400, Adam Jackson wrote:
 
> So from an OS maintenance perspective we have to recognize that
> bundling code occasionally does have merit, and that it is incumbent on
> us to manage it well.  And from a Fedora perspective, we have to
> acknowledge that a prohibition policy ignores that reality, that we
> have not consistently enforced it, and that we do ourselves and our
> users a disservice to insist on it.

It's actually a step worse than this as well - our policy on this (and
on .a files) actively discourages people from being Fedora contributors,
and discourages upstreams from working with us.

> Treat it as a bug, sure.  Work on it as a continual process of quality,
> absolutely.  Those are much more mature responses than a strict ban.
> 
> Reality is complicated, we would do well to recognize that.

Yup.

-- 
Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Zdenek Kabelac]

Dne 9.10.2015 v 16:41 Kevin Fenzi napsal(a):

On Fri, 9 Oct 2015 16:36:37 +0200
Zdenek Kabelac  wrote:


IMHO  all we need is to support  multiple version of same library
to be installable  -- that's mine point why  usability of Fedora
is miles behind other distros.

...snip...

We do.

If you need a different version of a library, you can make a compat
library. It's just assumed that you want the latest/current one.




If all it would take would be e.g. : dnf  install-compat

Otherwise you basically require  that every user of Fedora is supposedly quite 
skilled rpm package-maintainer ??
(Which would roughly cut the user-base  only to those who actively maintain 
package in Fedora)



Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Vít Ondruch]

Dne 9.10.2015 v 16:41 Kevin Fenzi napsal(a):
> On Fri, 9 Oct 2015 16:36:37 +0200
> Zdenek Kabelac  wrote:
>
>> IMHO  all we need is to support  multiple version of same library
>> to be installable  -- that's mine point why  usability of Fedora
>> is miles behind other distros.
> ...snip...
>
> We do. 
>
> If you need a different version of a library, you can make a compat
> library. It's just assumed that you want the latest/current one. 

This does not scale unfortunately ... and it is common excuse to not
support it properly. IOW, I want to have package foo-1.0 installed side
by side with foo-2.0 and I don't want to have foo1-1.0 side by side with
foo-2.0. And this applies especially for packages which are designed to
not conflict by design.


Vít
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Gerald B. Cox]

On Fri, Oct 9, 2015 at 11:02 AM, Ralf Corsepius  wrote:

> On 10/09/2015 03:51 PM, Matthew Miller wrote:
>
>> On Fri, Oct 09, 2015 at 01:50:27PM +0100, Richard W.M. Jones wrote:
>>
>>> This opens the door to all kinds of duplication, waste of disk space,
 waste
 of RAM, symbol conflicts and unfixed security issues!

>>> I agree - the new wording does appear to give in to poor programming
>>> practices.
>>>
>>
>> Do you have suggestions for improvements?
>>
>> Do I have to pronouce the obivious? FESCO to revert their faulty decision.


After reading these emails the last few weeks, I believe FESCo should be
commended.  This was just going to turn into
an endless morass - so they stepped in and took the pragmatic approach.
That is what leadership is all about.  Time to move on.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/09/2015 10:42 AM, Haïkel wrote:
> 2015-10-09 16:20 GMT+02:00 Neal Gompa :
>> 
>> A SIG dedicated to going through our packages and "systemizing"
>> them (e.g. unbundling them) would probably be a really good idea,
>> especially with the new rules. A group of packagers experienced
>> in this could be solicited to help with trickier packages. As it
>> is, it's pretty hard to solicit for help on packages. Last night,
>> I was in #fedora-devel, where someone was working on a package to
>> unbundle, and he was having a lot of trouble doing it on his own.
>> He didn't have to, but was trying to anyway.
>> 
>> I think our packagers generally want our packages to be
>> system-friendly, but sometimes it can be very hard. We have SIGs
>> to solicit experience for Python, Ruby, PHP, etc., why not have
>> one for this too?
>> 
>> Kevin, given that you're so passionate about this, why don't you
>> create the SIG and gather folks to help support such efforts? It
>> would be greatly appreciated.
>> 
>> 
> 
> +1 And I was serious about it, rather sticking to guidelines as if
> they were dogma, I prefer positive actions to fight poor
> practices.

I'm thoroughly behind this. I think an unbundling SIG is a far better
solution to the bundling problem than the high barrier-to-entry and
poor-enforcement solution that we had previously.

Having a group of motivated and knowledgeable individuals focused on
removing unnecessary bundling would be far more likely to result in
secure *and* usable software. I'd be more than happy to participate in
such a SIG as time allows.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlYX1okACgkQeiVVYja6o6NCNQCeJuKCg8nfAfZqSpLJF8S7iAAo
8OsAn06GUVmHzz8qf8XdCxS8yO2Sxq3U
=uVJd
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Jóhann B . Guðmundsson]

On 10/09/2015 02:16 PM, Adam Jackson wrote:

On Fri, 2015-10-09 at 13:50 +0100, Richard W.M. Jones wrote:


>I agree - the new wording does appear to give in to poor programming
>practices.

Bundling is_not_  intrinsically poor practice.  Firefox is a good
example of this, there have been several cases where using the system
instance of cairo has been a regression relative to the bundled
version, because firefox relied on the internal details of how a
particular version of cairo worked, and a newer and ostensibly better
cairo would break those assumptions.

Maybe we can argue that firefox was wrong to make those assumptions.
Maybe we can argue that cairo wasn't living up to its own interface
contract.  Who cares?  The result from the consumer's perspective is
that bundling produces a working firefox, and unbundling produces a
broken firefox, so bundling is desirable.  From the firefox developers'
perspective, bundling allows them to ship a product that is known to
actually work, so bundling is desirable.

So from an OS maintenance perspective we have to recognize that
bundling code occasionally does have merit, and that it is incumbent on
us to manage it well.  And from a Fedora perspective, we have to
acknowledge that a prohibition policy ignores that reality, that we
have not consistently enforced it, and that we do ourselves and our
users a disservice to insist on it.


Interesting taking the consumer perspective.

So where does FESCo intend to draw the line now that it has chosen to 
head down this path.


For example is the next step for Fedora to dissociate itself with 
upstream and start implementing "workarounds" instead of fixing things 
where they belong to satisfy the end users needs and expectation as well?


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Haïkel]

2015-10-09 16:20 GMT+02:00 Neal Gompa :
>
> A SIG dedicated to going through our packages and "systemizing" them (e.g.
> unbundling them) would probably be a really good idea, especially with the
> new rules. A group of packagers experienced in this could be solicited to
> help with trickier packages. As it is, it's pretty hard to solicit for help
> on packages. Last night, I was in #fedora-devel, where someone was working
> on a package to unbundle, and he was having a lot of trouble doing it on his
> own. He didn't have to, but was trying to anyway.
>
> I think our packagers generally want our packages to be system-friendly, but
> sometimes it can be very hard. We have SIGs to solicit experience for
> Python, Ruby, PHP, etc., why not have one for this too?
>
> Kevin, given that you're so passionate about this, why don't you create the
> SIG and gather folks to help support such efforts? It would be greatly
> appreciated.
>
>

+1
And I was serious about it, rather sticking to guidelines as if they
were dogma, I prefer positive actions to fight poor practices.

H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Fenzi]

On Fri, 9 Oct 2015 16:36:37 +0200
Zdenek Kabelac  wrote:

> IMHO  all we need is to support  multiple version of same library
> to be installable  -- that's mine point why  usability of Fedora
> is miles behind other distros.
...snip...

We do. 

If you need a different version of a library, you can make a compat
library. It's just assumed that you want the latest/current one. 

kevin


pgpH7rOuMzuJy.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Zdenek Kabelac]

Dne 9.10.2015 v 16:16 Adam Jackson napsal(a):

On Fri, 2015-10-09 at 13:50 +0100, Richard W.M. Jones wrote:


I agree - the new wording does appear to give in to poor programming
practices.


Bundling is _not_ intrinsically poor practice.  Firefox is a good
example of this, there have been several cases where using the system
instance of cairo has been a regression relative to the bundled
version, because firefox relied on the internal details of how a
particular version of cairo worked, and a newer and ostensibly better
cairo would break those assumptions.


IMHO  all we need is to support  multiple version of same library
to be installable  -- that's mine point why  usability of Fedora
is miles behind other distros.

Yeah - in ideal world - everyone uses always the latest library
and the library is perfectly compatible.

But in the real-world - version changes, it gets incompatible,
requires some new way how to use it and so on

So for the real-world  we simply need to be able to keep multiple
version of  e.g.  cairo

until all apps  used by users gets migrated to new version - it's that simple.


And BTW we don't need to go long way example - even core libs like
systemd/udev  tends to break compatibility from time to time.

Thus supporting  multiple lib of same package would have forced developers to 
think about their API instead of rebuilding whole Rawhide every second week 
just because library changes


This also solve the issue - when some no longer - but still very usable APP is 
missing - because I'd be able to pick  old libs - and downgrade rest of my 
rawhide -  or not having  app at all.


I really think  rules  should reflect real world - and not some kind of 
virtual ideal universe -  it should be a goal - but not with the price any 
Fedora user has to pay ATM...



Zdenek


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Fernando Nasser]

On 2015-10-09 10:02 AM, Ralf Corsepius wrote:

On 10/09/2015 03:51 PM, Matthew Miller wrote:

On Fri, Oct 09, 2015 at 01:50:27PM +0100, Richard W.M. Jones wrote:
This opens the door to all kinds of duplication, waste of disk 
space, waste

of RAM, symbol conflicts and unfixed security issues!

I agree - the new wording does appear to give in to poor programming
practices.


Do you have suggestions for improvements?

Do I have to pronouce the obivious? FESCO to revert their faulty 
decision.



+1
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Neal Gompa]

On Fri, Oct 9, 2015 at 5:45 AM, Haïkel  wrote:

> 2015-10-09 1:17 GMT+02:00 Kevin Kofler :
> > Haïkel wrote:
> >> Not that I'm 100% happy with the way it happened but this has been a
> >> very long-lived topic. To some, it'll be a hasty decision, to others,
> >> it's already a late one.
> >
> > There's a REASON it had always been shot down so far!
> >
> >> Please keep in mind, that Fesco is aware this is not a perfect
> >> solution, and we''ll gladly review any proposals to improve this
> >> policy.
> >
> > It is not possible to "improve" a policy that is fundamentally broken.
> The
> > only possible improvement is to repeal/revert it.
> >
> >> But we can keep discussing this for years, or try to solve this issue
> >> incrementally.
> >
> > Or we can just keep saying no, in compliance with our principles.
> >
> >> We chose the latter.
> >
> > What is "incremental" about this policy change? It is a radical U-turn.
> >
> >> No we didn't chose quantity over quality, it will only have a marginal
> >> impact on the former.
> >
> > Then it will even have failed its stated purpose.
> >
> >> It doesn't prevent you to do unbundling
> >
> > It does. The maintainer can now say "no" to any non-upstream unbundling.
> >
> >> Pretending that the now-previous guidelines that many packages
> >> (including recent ones) did not respect were preventing issues was
> >> giving a false impression of security, that was *harmful*.
> >
> > If existing packages were not compliant to the policy, that's the problem
> > you need to fix, by:
> > 1. fixing the packages (not just threatening their removal from Fedora,
> but
> >actually having a provenpackager go in and do the downstream
> unbundling),
> >and
>
> Sounds like you're volunteering for an Unbundling SIG, go ahead, you
> have blessing.
> I can even provide you a list of offending packages or ones that are
> not updated because of the unbundling efforts (ie: hadoop)
>
> Regards,
> H.
>
>
​A SIG dedicated to going through our packages and "systemizing" them (e.g.
unbundling them) would probably be a really good idea, especially with the
new rules. A group of packagers experienced in this could be solicited to
help with trickier packages. As it is, it's pretty hard to solicit for help
on packages. Last night, I was in #fedora-devel, where someone was working
on a package to unbundle, and he was having a lot of trouble doing it on
his own. He didn't have to, but was trying to anyway.

I think our packagers generally want our packages to be system-friendly,
but sometimes it can be very hard. We have SIGs to solicit experience for
Python, Ruby, PHP, etc., why not have one for this too?

Kevin, given that you're so passionate about this, why don't you create the
SIG and gather folks to help support such efforts? It would be greatly
appreciated.​




-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Adam Jackson]

On Fri, 2015-10-09 at 13:50 +0100, Richard W.M. Jones wrote:

> I agree - the new wording does appear to give in to poor programming
> practices.

Bundling is _not_ intrinsically poor practice.  Firefox is a good
example of this, there have been several cases where using the system
instance of cairo has been a regression relative to the bundled
version, because firefox relied on the internal details of how a
particular version of cairo worked, and a newer and ostensibly better
cairo would break those assumptions.

Maybe we can argue that firefox was wrong to make those assumptions.
Maybe we can argue that cairo wasn't living up to its own interface
contract.  Who cares?  The result from the consumer's perspective is
that bundling produces a working firefox, and unbundling produces a
broken firefox, so bundling is desirable.  From the firefox developers'
perspective, bundling allows them to ship a product that is known to
actually work, so bundling is desirable.

So from an OS maintenance perspective we have to recognize that
bundling code occasionally does have merit, and that it is incumbent on
us to manage it well.  And from a Fedora perspective, we have to
acknowledge that a prohibition policy ignores that reality, that we
have not consistently enforced it, and that we do ourselves and our
users a disservice to insist on it.

Treat it as a bug, sure.  Work on it as a continual process of quality,
absolutely.  Those are much more mature responses than a strict ban.

Reality is complicated, we would do well to recognize that.

- ajax
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Ralf Corsepius]

On 10/09/2015 03:51 PM, Matthew Miller wrote:

On Fri, Oct 09, 2015 at 01:50:27PM +0100, Richard W.M. Jones wrote:

This opens the door to all kinds of duplication, waste of disk space, waste
of RAM, symbol conflicts and unfixed security issues!

I agree - the new wording does appear to give in to poor programming
practices.


Do you have suggestions for improvements?


Do I have to pronouce the obivious? FESCO to revert their faulty decision.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Matthew Miller]

On Fri, Oct 09, 2015 at 01:50:27PM +0100, Richard W.M. Jones wrote:
> > This opens the door to all kinds of duplication, waste of disk space, waste 
> > of RAM, symbol conflicts and unfixed security issues!
> I agree - the new wording does appear to give in to poor programming
> practices.

Do you have suggestions for improvements?

-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Adam Jackson]

On Fri, 2015-10-09 at 01:22 +0200, Kevin Kofler wrote:
> Adam Jackson wrote:
> > From the consumer's perspective it makes zero difference whether a
> > particular library is bundled or not, as long as the app works.
> 
> Only until they run into their first symbol conflict due to conflicting 
> bundled libraries.

I'd call that the app not working, yes.  Symbol conflicts are literally
trivial to find, I'm really not sure why you bring the point up.

> And even if there are no symbol conflicts, they WILL notice that:
> 1. the bundled library wastes their disk space,
> 2. the bundled library wastes their RAM (because shared objects share most
>of their RAM segments, too), and
> 3. the bundled library wastes their time and bandwidth whenever downloading
>an application update.

Yes, I'm aware of the cost of bundling libraries.  But if the
alternative is not having the application available at all I'm
_entirely_ okay with that cost, because in that scenario what the user
notices is that Fedora is not usable.

- ajax
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Richard W.M. Jones]

On Thu, Oct 08, 2015 at 12:06:31AM +0200, Kevin Kofler wrote:
> Stephen Gallagher wrote:
> > * #1483 Decision on bundling policy in the Fedora Package Collection
> >   (sgallagh, 18:11:40)
> >   * LINK: http://paste.fedoraproject.org/276064/44243383/ is sgallaghs
> > proposal without the critpath distinction  (nirik, 18:43:49)
> >   * AGREED: Adjust the packaging policy as described in
> > http://paste.fedoraproject.org/276064/44243383/ (+5, 3, -1)
> > (sgallagh, 18:57:44)
> >   * ACTION: tibbs|w to inform FPC and work on removing the anti-bundling
> > stuff from the guidelines  (sgallagh, 18:59:17)
> 
> Ewww! :-(
> 
> This opens the door to all kinds of duplication, waste of disk space, waste 
> of RAM, symbol conflicts and unfixed security issues!

I agree - the new wording does appear to give in to poor programming
practices.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Ralf Corsepius]

On 10/09/2015 12:08 AM, Dominik 'Rathann' Mierzejewski wrote:

On Wednesday, 07 October 2015 at 21:17, Stephen Gallagher wrote:

Meeting summary
---

[...]

* #1483 Decision on bundling policy in the Fedora Package Collection
   (sgallagh, 18:11:40)
   * LINK: http://paste.fedoraproject.org/276064/44243383/ is sgallaghs
 proposal without the critpath distinction  (nirik, 18:43:49)
   * AGREED: Adjust the packaging policy as described in
 http://paste.fedoraproject.org/276064/44243383/ (+5, 3, -1)
 (sgallagh, 18:57:44)
   * ACTION: tibbs|w to inform FPC and work on removing the anti-bundling
 stuff from the guidelines  (sgallagh, 18:59:17)


This was handled far too quickly and without considering the full
consequences of the change that was passed. Also, the way you handled
this caused a lot of resentment among the FPC members (or at least
that's the impression I have).


Seconded.

What FESCO did was such kind of utterly disrespectful and rude toward FPC.

ATM, I consider it to be a matter politeness not furtherly pronounce my 
opinion because I would have to be personal.





--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Haïkel]

2015-10-09 1:17 GMT+02:00 Kevin Kofler :
> Haïkel wrote:
>> Not that I'm 100% happy with the way it happened but this has been a
>> very long-lived topic. To some, it'll be a hasty decision, to others,
>> it's already a late one.
>
> There's a REASON it had always been shot down so far!
>
>> Please keep in mind, that Fesco is aware this is not a perfect
>> solution, and we''ll gladly review any proposals to improve this
>> policy.
>
> It is not possible to "improve" a policy that is fundamentally broken. The
> only possible improvement is to repeal/revert it.
>
>> But we can keep discussing this for years, or try to solve this issue
>> incrementally.
>
> Or we can just keep saying no, in compliance with our principles.
>
>> We chose the latter.
>
> What is "incremental" about this policy change? It is a radical U-turn.
>
>> No we didn't chose quantity over quality, it will only have a marginal
>> impact on the former.
>
> Then it will even have failed its stated purpose.
>
>> It doesn't prevent you to do unbundling
>
> It does. The maintainer can now say "no" to any non-upstream unbundling.
>
>> Pretending that the now-previous guidelines that many packages
>> (including recent ones) did not respect were preventing issues was
>> giving a false impression of security, that was *harmful*.
>
> If existing packages were not compliant to the policy, that's the problem
> you need to fix, by:
> 1. fixing the packages (not just threatening their removal from Fedora, but
>actually having a provenpackager go in and do the downstream unbundling),
>and

Sounds like you're volunteering for an Unbundling SIG, go ahead, you
have blessing.
I can even provide you a list of offending packages or ones that are
not updated because of the unbundling efforts (ie: hadoop)

> 2. for blatant or repeat offenses, unsponsoring both the submitters and the
>reviewers of the offending packages.
>

Good luck with that, we can't even ban repeated offenders on this very
list, let alone packagers that let bundled libs sneak in.

>> You're free to rant or work with us to improve the now-current policy.
>
> See above, the policy cannot be "improved" because it is fundamentally
> flawed and the exact opposite of what the policy should be.
>
> Kevin Kofler
>

I read all above and I still believe that you're turning something
that has always been a best-effort goal into some kind of dogma.
New policy needs better wording and guidelines changes but it's not
that different from the previous one.

Unbundling will still be required when possible and necessary (e.g
dead upstream), but we have now a better footing to track bundled
libs, and stop misguided behaviours.

Regards,
H.

> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Kofler]

Brendan Conoboy wrote:
> Hey, you sound pretty upset.  The analogy on offer is quite extreme,
> presumably in proportion to how bothered you are, and unfortunately
> suggests a negative view of the those who proposed/supported the
> change.  Let's try a different analogy: Fedora is the house, the old
> bundling policy is is a compromised floor board, the new policy is a
> replacement floor board, but it needs to be sanded and stained.

No, the new policy is a frame that is being mislabeled as a floor board. 
Inside the frame, there is just no floor at all and you fall through and 
die.

Really, you basically REMOVED the policy for essentially all the cases that 
matter (because in those cases where upstream supports building against the 
system library, it is fairly obvious that it will be done even without a 
policy that says so), with no replacement at all.

And now you're asking us to turn that frame into a floor, which is just not 
practical to do in a way that does not leave huge gaping holes or crumble 
down as soon as you step on it.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Kofler]

Haïkel wrote:
> This was discussed, I remember that this very point being raised by rishi.
> We agreed (but not voted) that packages with dead upstream should
> unbundle.

But it is only policy if it is written down in the letter of the policy.

> => I don't think anyone is against strict unbundling for dead upstream
> package. Problem is how we detect that a package has a dead upstream :/

I don't follow the logic here: If it is possible to unbundle the library 
even with no upstream that could help at all, then surely it is just as 
possible to unbundle it when upstream is uncooperative! I don't see why an 
uncooperative upstream should be treated any differently from a dead 
upstream, for our purposes they are essentially the same.

> I personally even consider that such packages should just be dropped
> in the long-term.

I am strongly opposed to that!

Removing packages that work and are usually the ones requiring the least 
maintenance work (because there are no new releases to rebase to) is a major 
disservice to our users. Especially if there is no viable maintained 
alternative. (For example, I still use Quanta Plus from KDE 3 kdewebdev 
because there is just nothing comparable anywhere else in Fedora.) And some 
"dead" projects also get revived after some time, see e.g. Merkaartor that 
(after a few months of being "dead") got picked up upstream and ported from 
Qt 4 to Qt 5.

Only if the software stops working and we cannot fix it for whatever reason 
(e.g. because it depends on some web service that is no longer available), 
that is the time to retire it.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Brendan Conoboy]

On 10/08/2015 03:32 PM, Dominik 'Rathann' Mierzejewski wrote:

On Friday, 09 October 2015 at 00:14, Brendan Conoboy wrote:

On 10/08/2015 08:48 AM, Haïkel wrote:
[snip]

Please keep in mind, that Fesco is aware this is not a perfect
solution, and we''ll gladly review any proposals to improve this
policy. But we can keep discussing this for years, or try to solve
this issue incrementally. We chose the latter.

[snip]

Replying to highlight this piece.  The passed proposal is an improvement: it
opens Fedora to more participants, it better reflects some upstream
realities, and best of all it can be further amended. As people have the
time and inclination they can and should propose further improvements- Fesco
is clearly open to and expecting this, so if you have an idea on how to
further improve the bundling policies, please propose it.  In this way
Fedora gets better and better over time.


Forgive me the analogy, but to me it looked like this:
Some vocal people don't like this old scary building we have. Let's destroy
the building completely, put up a nicely painted shed in its place and
hope someone will "improve it". I believe it would've been easier to
renovate the old building than to rebuild everything from the ground up.


Hey, you sound pretty upset.  The analogy on offer is quite extreme, 
presumably in proportion to how bothered you are, and unfortunately 
suggests a negative view of the those who proposed/supported the 
change.  Let's try a different analogy: Fedora is the house, the old 
bundling policy is is a compromised floor board, the new policy is a 
replacement floor board, but it needs to be sanded and stained.  You 
would prefer this finish work be done before pulling the old board. 
The carpenter (Fesco) decided to replace the board before finishing. 
This lets everybody evaluate how much sanding and finishing is 
necessary to get the new board to match the rest of the floor.  It's 
clear you have specific and reasonable concerns about the new language 
and it should be very straight forward to propose alterations that 
Fesco can support.


--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Kofler]

Adam Jackson wrote:
> From the consumer's perspective it makes zero difference whether a
> particular library is bundled or not, as long as the app works.

Only until they run into their first symbol conflict due to conflicting 
bundled libraries.

And even if there are no symbol conflicts, they WILL notice that:
1. the bundled library wastes their disk space,
2. the bundled library wastes their RAM (because shared objects share most
   of their RAM segments, too), and
3. the bundled library wastes their time and bandwidth whenever downloading
   an application update.

> Any undiscovered security bug (for instance) will be there in the
> unbundled copy of the library too.

But a discovered and fixed security bug will not! Good luck ensuring that 
when the library is bundled throughout the distribution.

> And, to be honest, we're failing at tracking bundling _already_,
> regardless of this particular change in policy.  clamav bundles a copy
> of llvm, ffs.  Policies that are out of line with reality are bad
> policy: the war on drugs does not fix drug abuse, vagrancy laws do not
> fix poverty, and the war on bundling merely ensures that bundled
> software goes unreported.

That is willful abuse of the packaging guidelines and should really lead to 
the packager getting unsponsored if it's done on purpose.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Kofler]

Haïkel wrote:
> Not that I'm 100% happy with the way it happened but this has been a
> very long-lived topic. To some, it'll be a hasty decision, to others,
> it's already a late one.

There's a REASON it had always been shot down so far!

> Please keep in mind, that Fesco is aware this is not a perfect
> solution, and we''ll gladly review any proposals to improve this
> policy.

It is not possible to "improve" a policy that is fundamentally broken. The 
only possible improvement is to repeal/revert it.

> But we can keep discussing this for years, or try to solve this issue
> incrementally.

Or we can just keep saying no, in compliance with our principles.

> We chose the latter.

What is "incremental" about this policy change? It is a radical U-turn.

> No we didn't chose quantity over quality, it will only have a marginal
> impact on the former.

Then it will even have failed its stated purpose.

> It doesn't prevent you to do unbundling

It does. The maintainer can now say "no" to any non-upstream unbundling.

> Pretending that the now-previous guidelines that many packages
> (including recent ones) did not respect were preventing issues was
> giving a false impression of security, that was *harmful*.

If existing packages were not compliant to the policy, that's the problem 
you need to fix, by:
1. fixing the packages (not just threatening their removal from Fedora, but
   actually having a provenpackager go in and do the downstream unbundling),
   and
2. for blatant or repeat offenses, unsponsoring both the submitters and the
   reviewers of the offending packages.

> You're free to rant or work with us to improve the now-current policy.

See above, the policy cannot be "improved" because it is fundamentally 
flawed and the exact opposite of what the policy should be.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Kofler]

Vít Ondruch wrote:
> Nothing can stop you fighting against bundling, checking packages,
> reporting bundling, working with upstream on unbundling etc. You could
> at least try to take a positive view, not the most negative you can.

If the maintainer refuses to unbundle against upstream's wishes, under that 
new policy, there is nothing I can do, even if the patch to unbundle would 
be trivial.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Haïkel]

2015-10-09 0:08 GMT+02:00 Dominik 'Rathann' Mierzejewski
:
> On Wednesday, 07 October 2015 at 21:17, Stephen Gallagher wrote:
>> Meeting summary
>> ---
> [...]
>> * #1483 Decision on bundling policy in the Fedora Package Collection
>>   (sgallagh, 18:11:40)
>>   * LINK: http://paste.fedoraproject.org/276064/44243383/ is sgallaghs
>> proposal without the critpath distinction  (nirik, 18:43:49)
>>   * AGREED: Adjust the packaging policy as described in
>> http://paste.fedoraproject.org/276064/44243383/ (+5, 3, -1)
>> (sgallagh, 18:57:44)
>>   * ACTION: tibbs|w to inform FPC and work on removing the anti-bundling
>> stuff from the guidelines  (sgallagh, 18:59:17)
>
> This was handled far too quickly and without considering the full
> consequences of the change that was passed. Also, the way you handled
> this caused a lot of resentment among the FPC members (or at least
> that's the impression I have). Now, personal feelings aside, I do have
> some technical points to make, with my FPC hat on.
>

Thanks for doing that.


> The new wording completely drops the requirement for package maintainers
> to at least attempt unbundling on their own if upstream doesn't want to
> support it. In many cases, it's quite trivial and should be required,
> especially if upstream has a testsuite and it passes with downstream
> unbundling.
>

Ack, makes sense.

> You completely ignored the case when upstream is dead and cannot be
> contacted (and, for example the upstream of the bundled code is not).
>

This was discussed, I remember that this very point being raised by rishi.
We agreed (but not voted) that packages with dead upstream should unbundle.

I personally even consider that such packages should just be dropped
in the long-term.

=> I don't think anyone is against strict unbundling for dead upstream package.
Problem is how we detect that a package has a dead upstream :/

> Additionally, there's no requirement to maintain sanity in the bundled
> Provides: naming. You should have at least mandated that the maintainer
> checks existing packaged and/or bundled package names and uses the same
> name if the code is bundled in a new package. FPC or at least the
> packaging list should be consulted in case of any doubts here. We have
> considerable experience in this area and we (used to) maintain a canonical
> list of bundled(foo) provides. I believe it makes sense that we keep
> doing it.
>

*nods*
If FPC is willing to do that, that's fine with me.

> Finally, the wording speaks about libraries, completely ignoring the
> fact that very often, only single files or even code snippets are
> bundled and these need to be tracked as well. You haven't defined
> what a "library" is.
>

Yeah, many packages bundle crypto and checksum code, and these needs
to be tracked.

Any wording clarifications should be welcome, but I guess we'll have
to review this topic during fesco meeting again.

Regards,
H.


> Regards,
> Dominik
> --
> Fedora http://fedoraproject.org/wiki/User:Rathann
> RPMFusion http://rpmfusion.org
> "Faith manages."
> -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Dominik 'Rathann' Mierzejewski]

On Friday, 09 October 2015 at 00:14, Brendan Conoboy wrote:
> On 10/08/2015 08:48 AM, Haïkel wrote:
> [snip]
> >Please keep in mind, that Fesco is aware this is not a perfect
> >solution, and we''ll gladly review any proposals to improve this
> >policy. But we can keep discussing this for years, or try to solve
> >this issue incrementally. We chose the latter.
> [snip]
> 
> Replying to highlight this piece.  The passed proposal is an improvement: it
> opens Fedora to more participants, it better reflects some upstream
> realities, and best of all it can be further amended. As people have the
> time and inclination they can and should propose further improvements- Fesco
> is clearly open to and expecting this, so if you have an idea on how to
> further improve the bundling policies, please propose it.  In this way
> Fedora gets better and better over time.

Forgive me the analogy, but to me it looked like this:
Some vocal people don't like this old scary building we have. Let's destroy
the building completely, put up a nicely painted shed in its place and
hope someone will "improve it". I believe it would've been easier to
renovate the old building than to rebuild everything from the ground up.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Brendan Conoboy]

On 10/08/2015 08:48 AM, Haïkel wrote:
[snip]

Please keep in mind, that Fesco is aware this is not a perfect
solution, and we''ll gladly review any proposals to improve this
policy. But we can keep discussing this for years, or try to solve
this issue incrementally. We chose the latter.

[snip]

Replying to highlight this piece.  The passed proposal is an 
improvement: it opens Fedora to more participants, it better reflects 
some upstream realities, and best of all it can be further amended. 
As people have the time and inclination they can and should propose 
further improvements- Fesco is clearly open to and expecting this, so 
if you have an idea on how to further improve the bundling policies, 
please propose it.  In this way Fedora gets better and better over time.


--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 07 October 2015 at 21:17, Stephen Gallagher wrote:
> Meeting summary
> ---
[...]
> * #1483 Decision on bundling policy in the Fedora Package Collection
>   (sgallagh, 18:11:40)
>   * LINK: http://paste.fedoraproject.org/276064/44243383/ is sgallaghs
> proposal without the critpath distinction  (nirik, 18:43:49)
>   * AGREED: Adjust the packaging policy as described in
> http://paste.fedoraproject.org/276064/44243383/ (+5, 3, -1)
> (sgallagh, 18:57:44)
>   * ACTION: tibbs|w to inform FPC and work on removing the anti-bundling
> stuff from the guidelines  (sgallagh, 18:59:17)

This was handled far too quickly and without considering the full
consequences of the change that was passed. Also, the way you handled
this caused a lot of resentment among the FPC members (or at least
that's the impression I have). Now, personal feelings aside, I do have
some technical points to make, with my FPC hat on.

The new wording completely drops the requirement for package maintainers
to at least attempt unbundling on their own if upstream doesn't want to
support it. In many cases, it's quite trivial and should be required,
especially if upstream has a testsuite and it passes with downstream
unbundling.

You completely ignored the case when upstream is dead and cannot be
contacted (and, for example the upstream of the bundled code is not).

Additionally, there's no requirement to maintain sanity in the bundled
Provides: naming. You should have at least mandated that the maintainer
checks existing packaged and/or bundled package names and uses the same
name if the code is bundled in a new package. FPC or at least the
packaging list should be consulted in case of any doubts here. We have
considerable experience in this area and we (used to) maintain a canonical
list of bundled(foo) provides. I believe it makes sense that we keep
doing it.

Finally, the wording speaks about libraries, completely ignoring the
fact that very often, only single files or even code snippets are
bundled and these need to be tracked as well. You haven't defined
what a "library" is.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Adam Jackson]

On Thu, 2015-10-08 at 10:55 +0200, Tomas Mraz wrote:

> Yes, it seems the quantity over quality view won. :(

This is a false dichotomy.  The ultimate metric of quality is whether
the distribution contains a working copy of the software you want to
run.  Bundling is a maintenance concern for _people working on the
distribution_.  From the consumer's perspective it makes zero
difference whether a particular library is bundled or not, as long as
the app works.  Any undiscovered security bug (for instance) will be
there in the unbundled copy of the library too.

And, to be honest, we're failing at tracking bundling _already_,
regardless of this particular change in policy.  clamav bundles a copy
of llvm, ffs.  Policies that are out of line with reality are bad
policy: the war on drugs does not fix drug abuse, vagrancy laws do not
fix poverty, and the war on bundling merely ensures that bundled
software goes unreported.  We should acknowledge that bundling is a
real thing that solves real problems for both app developers and end
users, we should codify it in our policies, and we should build the
tools that enable us to track and manage it rather than pretend it
doesn't happen just because a package passed review once.

So yes, it makes life harder for the people building the distribution,
that's the entire point.  That's labor that _we_ take on precisely so
our users don't have to care.  That's not "quantity over quality",
that's quality as job one.  

- ajax
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Haïkel]

2015-10-08 10:55 GMT+02:00 Tomas Mraz :
> On Čt, 2015-10-08 at 00:06 +0200, Kevin Kofler wrote:
>> Stephen Gallagher wrote:
>> > * #1483 Decision on bundling policy in the Fedora Package Collection
>> >   (sgallagh, 18:11:40)
>> >   * LINK: http://paste.fedoraproject.org/276064/44243383/ is sgallaghs
>> > proposal without the critpath distinction  (nirik, 18:43:49)
>> >   * AGREED: Adjust the packaging policy as described in
>> > http://paste.fedoraproject.org/276064/44243383/ (+5, 3, -1)
>> > (sgallagh, 18:57:44)
>> >   * ACTION: tibbs|w to inform FPC and work on removing the anti-bundling
>> > stuff from the guidelines  (sgallagh, 18:59:17)
>>
>> Ewww! :-(
>>
>> This opens the door to all kinds of duplication, waste of disk space, waste
>> of RAM, symbol conflicts and unfixed security issues!
>>
>> "Thanks" for making Fedora worse!
>
> Yes, it seems the quantity over quality view won. :(
> Also the haste with which it was pushed is seriously disappointing.
>
> --
> Tomas Mraz
> No matter how far down the wrong road you've gone, turn back.
>   Turkish proverb
> (You'll never know whether the road is wrong though.)
>

Not that I'm 100% happy with the way it happened but this has been a
very long-lived topic. To some, it'll be a hasty decision, to others,
it's already a late one.

Please keep in mind, that Fesco is aware this is not a perfect
solution, and we''ll gladly review any proposals to improve this
policy. But we can keep discussing this for years, or try to solve
this issue incrementally. We chose the latter.
No we didn't chose quantity over quality, it will only have a marginal
impact on the former. It doesn't prevent you to do unbundling, track
bundled libraries, request FPC or peers feedback if you want.
Pretending that the now-previous guidelines that many packages
(including recent ones) did not respect were preventing issues was
giving a false impression of security, that was *harmful*.

You're free to rant or work with us to improve the now-current policy.

Regards,
H.

PS: I won't reply to private answers on that topic. It's either on the
list or it'll go to /dev/null
PPS: I encourage people complaining to participate more actively in
the reviewing pipeline, best way to prevent bundled libraries to be
sneaked in. Sloppy reviews and the lack of regular reviewing process
for current packages are a far more serious issue.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Tomas Mraz]

On Čt, 2015-10-08 at 00:06 +0200, Kevin Kofler wrote:
> Stephen Gallagher wrote:
> > * #1483 Decision on bundling policy in the Fedora Package Collection
> >   (sgallagh, 18:11:40)
> >   * LINK: http://paste.fedoraproject.org/276064/44243383/ is sgallaghs
> > proposal without the critpath distinction  (nirik, 18:43:49)
> >   * AGREED: Adjust the packaging policy as described in
> > http://paste.fedoraproject.org/276064/44243383/ (+5, 3, -1)
> > (sgallagh, 18:57:44)
> >   * ACTION: tibbs|w to inform FPC and work on removing the anti-bundling
> > stuff from the guidelines  (sgallagh, 18:59:17)
> 
> Ewww! :-(
> 
> This opens the door to all kinds of duplication, waste of disk space, waste 
> of RAM, symbol conflicts and unfixed security issues!
> 
> "Thanks" for making Fedora worse!

Yes, it seems the quantity over quality view won. :(
Also the haste with which it was pushed is seriously disappointing.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Vít Ondruch]

Dne 8.10.2015 v 00:06 Kevin Kofler napsal(a):
> Stephen Gallagher wrote:
>> * #1483 Decision on bundling policy in the Fedora Package Collection
>>   (sgallagh, 18:11:40)
>>   * LINK: http://paste.fedoraproject.org/276064/44243383/ is sgallaghs
>> proposal without the critpath distinction  (nirik, 18:43:49)
>>   * AGREED: Adjust the packaging policy as described in
>> http://paste.fedoraproject.org/276064/44243383/ (+5, 3, -1)
>> (sgallagh, 18:57:44)
>>   * ACTION: tibbs|w to inform FPC and work on removing the anti-bundling
>> stuff from the guidelines  (sgallagh, 18:59:17)
> Ewww! :-(
>
> This opens the door to all kinds of duplication, waste of disk space, waste 
> of RAM, symbol conflicts and unfixed security issues!
>
> "Thanks" for making Fedora worse!
>
> Kevin Kofler
>

Nothing can stop you fighting against bundling, checking packages,
reporting bundling, working with upstream on unbundling etc. You could
at least try to take a positive view, not the most negative you can.


Vít
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Kevin Kofler]

Stephen Gallagher wrote:
> * #1483 Decision on bundling policy in the Fedora Package Collection
>   (sgallagh, 18:11:40)
>   * LINK: http://paste.fedoraproject.org/276064/44243383/ is sgallaghs
> proposal without the critpath distinction  (nirik, 18:43:49)
>   * AGREED: Adjust the packaging policy as described in
> http://paste.fedoraproject.org/276064/44243383/ (+5, 3, -1)
> (sgallagh, 18:57:44)
>   * ACTION: tibbs|w to inform FPC and work on removing the anti-bundling
> stuff from the guidelines  (sgallagh, 18:59:17)

Ewww! :-(

This opens the door to all kinds of duplication, waste of disk space, waste 
of RAM, symbol conflicts and unfixed security issues!

"Thanks" for making Fedora worse!

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct