Summary/Minutes for today's FESCo meeting (2012-12-19)

Lennart Poettering mzerqung at 0pointer.de
Fri Dec 21 13:15:05 UTC 2012


On Thu, 20.12.12 18:48, Toshio Kuratomi (a.badger at gmail.com) wrote:

> > Ahem. Isn't your own first sentence suggesting that *your* way is the
> > one and only right way? I don't see how you can attack Lennart for
> > having a firm belief about what's the 'right way' when you also seem to
> > have a firm belief about what's the 'right way'...
> > 
> The FPC Guidelines give package maintainers the option of using
> %{_libexecdir}, %{_libdir}.  The recent changes that I worked on allow
> %{_prefix}/lib in certain cases.  When FPC at large decided that portions of
> what systemd wanted to do still didn't completely fall under those cases,
> I took the request from FPC that FESCo simply grant a special exception for
> systemd to FESCo.
> 
> So if you're arguing that my firm belief is also a right way or the highway,
> belief then you aren't arguing about the use of lib, libexec, and lib64
> anymore.  You're opening up a much larger conversation about whether
> top-down or bottom-up decision making is the direction that Fedora should be
> taking in the future; whether Fedora "management" should decide on one and
> only one way to do things and then force every packager to do things that
> way.
> 
> But if you want to go that route on this question, then it should be noted
> that FPC ruled that the use that systemd makes of
> %{_prefix}/lib was wrong under the prior guidelines but the systemd
> maintainers refused to make their package conform.  So while you might pose
> that question it's not likely to have a more desirable outcome for the
> systemd package maintainers than what they have now.

BTW, I am fine with giving packages a certain amount of freedom how they
want to handle things, but I also believe that guidelines should
*guide*, i.e. suggest a a way to go, and I believe that suggested way to
go is lib/<package> rather than %{_libexecdir}.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list