Only FESCo members should set the 'meeting' flag. This ticket came in after the agenda was set. It may be proposed for inclusion in Open Floor if there is time, but otherwise it should wait until next week.

From yesterday's announcement I understood that the agenda was still open, but I am in no hurry on this...

Replying to [comment:2 sgallagh]:

Only FESCo members should set the 'meeting' flag.

Sorry about this!

I (clearly) misunderstood this sentence in the FESCO wiki page - "Add 'meeting' to the keywords if you want it to be a topic of the next meeting". :)

We discussed this at todays fesco meeting, but ran into a question:

Why is it not possible to just build this for needed branches and install the dynamically linked version in the mock chroot?

Sorry, I was not able to join the meeting yesterday. It is of course possible to build cscppc/cswrap for all currently supported products (assuming we revert the patches dropping RHEL-5 compatibility). However, how can we get them installed into the chroot fully automatically?

Should csmock guess the branch based on name of the mock profile and download/install the appropriate binary RPMs on its own? Or should the user be required to extend the mock profile such that it contains yum repositories providing the binary packages of cscppc/cswrap? It means adding EPEL-5 repository to the RHEL-5-x86_64 mock profile, for instance...

Would it be more acceptable for FESCO if we provided *-static subpackages with statically linked executables while the basic cswrap/cscppc packages would provide dynamically linked executables? Is there any precedence for such a solution?

Replying to [comment:7 kdudka]:

Should csmock guess the branch based on name of the mock profile and download/install the appropriate binary RPMs on its own?

Right, that might be non-trivial. (Or is there a way to reliably and reasonably easily identify the "family" of a mock config, e.g. the %dist value, regardless of mock config name, and preferably without setting up a "test" chroot only to read /etc/rpm/macros.dist?)

The remark that "mock is in EPEL" during the FESCo meeting that caused me to withdraw my proposal is actually irrelevant—being able to add packages to the outside-chroot mock repo doesn't help with the inside-chroot setup.

So I'm back to +1 to adding the exception:
There is no security harm in static linking
The other disadvantages of it would cause extra work for you as the package maintainer, who asked for this extra work :)
* Even if we could get a practical way to add the wrappers as separate packages to various EPELs, doing all the separate packaging and builds, and keeping the ABIs of the wrappers in sync is fairly unnecessary overhead, considering how small the wrappers after all are.

Would it be more acceptable for FESCO if we provided *-static subpackages with statically linked executables while the basic cswrap/cscppc packages would provide dynamically linked executables?

This wouldn't avoid the use of the statically-linked binaries, and just add overhead for no end-user benefit. If Fedora policies allowed or encouraged such dysfunctional "solutions", that would be an indication that we need to urgently work on changing them.

I am +1 to the exception as well.

Copying statically-linked binaries into the chroot is a horrible hack. The right approach is really to build the packages for the appropriate branch, and then get those into the mock chroot as normal packages. If the packages get pushed to the official EPEL repositories, those are configured by default in our mock config files, so "mock -r epel-5-x86_64 install cscppc cwrap" should be all that's needed to trigger the installation from outside the chroot. I really don't see where the problem is.

Replying to [comment:10 kkofler]:

Copying statically-linked binaries into the chroot is a horrible hack. The right approach is really to build the packages for the appropriate branch, and then get those into the mock chroot as normal packages.

Yes, that is another approach already mentioned on top of this page. I would not call it "the right approach" as it provides limited user experience compared to the solution in question.

If the packages get pushed to the official EPEL repositories, those are configured by default in our mock config files, so "mock -r epel-5-x86_64 install cscppc cwrap" should be all that's needed to trigger the installation from outside the chroot. I really don't see where the problem is.

That would work for epel-5-x86_64. It will not work for rhel-5-x86_64 without additional care. The same holds for any other user-provided mock profile we have not covered in advance.

Agreed on today's FESCo meeting: Static linking exception for cscppc and cswrap approved (+6 -1 0:2)

Thanks for the approval!