Michael, thx for you comments. Am Montag, den 13.02.2006, 19:55 +0100 schrieb Michael Schwendt: > On Mon, 13 Feb 2006 18:22:42 +0100, Thorsten Leemhuis wrote: > > > Do all packages need a rebuild? > > Yes. > No. Well, we discussed the mass rebuild in at least tree meetings. The rebuild "all" or "only parts" was not explicit discussed, but from what I saw on the lists and in the meetings it seemed to me that a "rebuild everything" solution was what most people wanted. We can revisit that next Thursday if you want. > > Most noarch packages probably would work fine without a rebuild and > > won't have a benefit from the new gcc security features. But we know > > that some noarch package are broken due to changes in rawhide -- we'd > > like to catch and fix those. And we want to make sure that a package > > still has a active maintainer while at it. > > It's still short-sighted, since > > 1) A forced rebuild, just to check whether a package still builds, is > something that can be done by the maintainer _locally_ using mock or with > FC5 Test 3. You forget that we have some packagers that live in parts of the world where internet bandwidth is costly. I suspect that each rebuild for devel with mock will download 300 - 750 MByte. To much for those packagers afaics. And even if that wasn't a problem -- how do we make sure that people really tried if a package still builds? > 2) There are exceptions. Noarch packages which really don't need a rebuild. > Either it does or it doesn't. If it doesn't, the rebuild/update is not > needed. Maybe -- but where is the problem with rebuild? Yeah, packagers have to invest a bit of time to increase the Release, add a changelog entry and request build. But other that that is mostly machine time that is spend. > > What happens with packages where no one stepped up to rebuild them? > > > > Ehhh, we didn't talk about that to much yet. Maybe we'll file bugs after > > the rebuild flood goes back and ask the package-maintainer to rebuild > > his or her package(s). Or we simply rebuild them and ignore the > > maintainer -- but in that case we can't be sure that the maintainer is > > still active in Fedora Extras. > > We can't be sure of that anyway, because who checks whether more than > a rebuild would make sense? E.g. new upstream releases not been applied > prior to a rebuild done by the maintainer. We should rely a bit more on > the user community who helps with reporting packages which are out-of-date > or broken. I'd really like to see each maintainer doing some work now and then just to make sure that he is still active in FE and alive. And we have a lot of not that important packages in the tree now, some of them are rarely updated upstream (take tiobench for example). We might never notice if that package is orphaned if we always do a script-mass-rebuild... > > What happens with the old packages build before February the 13th 2006? > > > > They'll probably be removed from the repo before FE5 goes live. > > Veto. Just to make sure: this part belongs under the "Ehhh, we didn't talk about that to much yet." -- this wasn't obvious (there was only the "probably" in the sentence"), sorry for that. > Removing broken orphans can cause enough poor dep breakage already > during a Yum upgrade. So let's keep the number of removed packages low. Mind > you, a broken installed package is not excluded from a transaction check, > so anything that's installed already but missing in the repository is bad > (as it won't be upgraded with something working and will cause the upgrade > to fail). If you remove more than what is known to be broken, this increases > the risk of breaking even further, at least for some users. > > We may remove what's broken and track it on the FC5Status page in the > Wiki just as we did for FE4 and older. Well, let's see how this whole thing works out. But what I'd really like to remove before we publish FE5 are old packages from the tree when a successor is there. E.g. when both foo-1.2.FC4 and foo-1.3.FC5 are in the FE5 tree remove foo-1.2.FC4. That okay for everybody? CU thl -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
