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@xxxxxxxxxx> Associate Software Engineer - Base Operating Systems Brno PGP: 71A1677C Red Hat Inc. http://cz.redhat.com
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
