Adding packages to buildroot directly from updates-testing

[Stanislav Ochotnicky]

On 12/17/2010 07:34 PM, Matt McCutchen wrote:
> On Fri, 2010-12-17 at 18:32 +0100, Ralf Corsepius wrote:
>> * we are building packages against the known-to-be-broken package
> 
> The old package is already in stable.  We're not doing additional harm
> by building against it unless the "breakage" is a regression that
> affects the building of dependent packages.  At most, we waste the
> effort of performing the build.



I was recently fixing bug in maven2. Due to other changes in F14 maven2
failed to build. In order to fix the bug I had to build ~ 5 other
packages in order. It took me 1 month to fix one small bug. Yes I could
have filed releng ticket (I actually did to try it out in the end).
Unless someone:
1. files a ticket
2. contacts releng on IRC
it takes 1 day to get something to buildroot (due to TZ differences and
rdieter being basically the only one doing it). So even then it would be
more than a week for simple bug to be fixed. I agree with some other
poster(s) that this would be partially solved by more relengs taking
care of buildroot overrides.

>> whose 
>> replacements already are waiting in updates-testing.
> 
>> * we are building packages against packages in updates, which are known 
>> to be replaced with the versions from updates-testing.
> 
> The point is that is not true!  A significant fraction of builds in
> updates-testing do not go to stable because some problem is found with
> them.  Unfortunately, the data at
> https://fedorahosted.org/fesco/ticket/517 do not tell us this fraction.
> I have added a comment there requesting better data.

OK, but as we've said before...most fixes are runtime and shouldn't
affect builds. We don't generally do soname bumps or similar things in
stable releases. Yes I agree there are potential problems with building
against something in updates-testing that will later get pulled.
Something like:

I build package B against A-1.2.0 from testing, but A-1.2.0 is pulled.
So we would end up with B built against A-1.2.0 but running with
A-1.1.0. Let's assume B does built-time quessing about A and it finds
out A-1.2.0 supports this new great feature/api. So it builds itself
with support for this api which A-1.1.0 doesn't have. This could be
caught during tagging from testing to stable. During tagging we would
install package on a system and check if all symbols in binaries can be
resolved. Sounds reasonable? I am sure we can think of other disaster
scenarios, but please bear in mind that packages in updates-testing are
deemed worthy of being in stable Fedora within few days...

Whole thing is not NP-complete problem. What is the actual problem of
enhancing koji (or whatver bits of our infrastructure) that would
support operation where buildroot from testing could work in a safe
manner. How obout optional "build my package against stable not
updates-testing" in koji/fedpkg for security updates or packages that
are known to use compile time tweaks to how they use their dependencies
(I am guessing there will be very few of them).

There *must* be ways to speed up and simplify our work. I am sure people
would love to enhance our workflow, but my view is that currently very
few people know how our infrastructure (especially koji) really works
and how they could contribute to improving it.

-- 
Stanislav Ochotnicky <sochotnicky at redhat.com>
Associate Software Engineer - Base Operating Systems Brno

PGP: 71A1677C
Red Hat Inc.                               http://cz.redhat.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20101222/b5277fba/attachment.bin