On Fri, 2009-05-15 at 12:24 +0000, Duncan wrote: > Daniel Pielmeier <daniel.pielme...@googlemail.com> posted > 6142e6140905150344y4a8007b5wd352ffe891e49...@mail.gmail.com, excerpted > below, on Fri, 15 May 2009 12:44:47 +0200: > > > 2009/5/15 Marijn Schouten (hkBst) <hk...@gentoo.org>: > >> > >> Thilo Bangert wrote: > >>> > >>> Fedora is a much more current distribution than Gentoo - and has been > >>> for a couple of years... > >> > >> Please elaborate what exactly you think Fedora does better than we do. > >> I have no first-hand experience with Fedora, but from what I read I had > >> the impression that sometimes they go with new stuff before it is > >> ready, like KDE4 and pulseaudio. I like about the current situation > >> that we also have all those things available AFAICS, but have very > >> broad choices in how much we want to bleed. IMO this is a different > >> issue than having supposedly popular ebuilds not in main tree. > >> > > AFAIK Fedora is [Red Hat's unstable.] So it makes more sense to > > compare it with the Gentoo unstable tree instead of the stable > > one. Assuming this there is probably not a big difference in the > > up-to-dateness. > > Well, yes and no. As the GP said, they sometimes go with new stuff > before it's ready -- before Gentoo even has it in-tree hard-masked let > alone ~arch, while it's still in the various project overlays. I know > they've had some serious issues with xorg on Intel GPUs at least, due to > running versions that aren't in our tree yet, only in the X overlay, > because Fedora is running clearly not even ~arch-ready packages, > sometimes even xorg prereleases.
I believe you are thinking of rawhide. Fedora and quite most other distributions work fundamentally different. We have a gradually moving tree, as we can do that by being source based. Fedora and other distributions are doing releases, which involves switching to a newer repository branch with dist-upgrade and so on. They release a new version typically every 6 month, we release new major versions of packages all the time (considering the whole set). I'd say that at the point of binary distribution releases their released trees are somewhere between our ~arch and stable tree, while within a month or two, they become similar to our stable tree until our continous releases overcome it with newer versions. Fedora has xorg prereleases in what they call "rawhide". This is what will become a new release in the future, as they have ~6 month cycles. It's unstable on purpose, as they are thriving towards being stable with that repository at the time of the planned next release, while having up to date packages around the time of the release (with a ~1 month stabilization period before the release time). That's the fundamental difference, and where we can have an advantage over them in addition to other things coming from being source based. > Years ago we'd have put these in-tree but hard-masked for those who > wanted to try them. Now, depending on the package and Gentoo but more > likely as the complexity rises to meta-package levels, those who want to > try them must load an overlay. As someone who selectively unmasks and > tries these, having them in-tree but hard-masked is convenient, but I > understand why projects may prefer overlays in many cases. We do tend to prefer overlays in many cases for unstable releases. The project proposal at hand is of course talking about packages that are not available at all in the main tree yet. Overlays are quite nice for tracking unstable releases of package sets that do have their upstream stable releases in official tree. > However, none of this directly applies to the subject at hand, because > while we're talking new versions of packages already in-tree here, the > subject at hand is packages that aren't in-tree in any form yet. Sorry, still felt like replying with my view on Gentoo vs dist-upgraded distros :) -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
