Beso <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Tue, 25 Nov 2008 12:16:56 +0100:
> 2008/11/25 Duncan <[EMAIL PROTECTED]>: >> "Mark Knecht" <[EMAIL PROTECTED]> posted >> [EMAIL PROTECTED], excerpted >> below, on Mon, 24 Nov 2008 14:46:35 -0800: >> >>>> Personally, I default to ~arch, and unmask hard-masked packages >>>> either in- tree or from various overlays from time to time as well. >>> >>> Where do you do this? In /etc/make.conf? I've never run a machine like >>> that but would be interested in at least seeing how many packages this >>> machine would have to rebuild if I went there. >> >> Yes, I set ACCEPT_KEYWORDS=~amd64 (which automatically includes stable >> amd64 as well, as shown by an emerge --info) in /etc/make.conf. You'd >> be surprised at how far out of date stable arch is in some cases. Of >> course in other cases, generally mature and real slow moving packages, >> the latest version available has long been stable on most or all archs >> (see below). >> > if i recall corectly in the past some packages that were under amd64 > only needed also accept keywords amd64 near ~amd64. has this changed > lately? usually the latest includes the former but sometimes when the > packages are just amd64 and no ~amd64 ones i remember that i needed to > add amd64 also in the keywords. I'm not saying it can't happen, but if it does, it's certainly a bug, either of the package (not testing the keyword correctly) or of portage (not setting it correctly), or possibly of the user (maybe a typo, ~adm64 instead of ~amd64, say). Here's what I know: >From my make.conf: ACCEPT_KEYWORDS="~amd64" emerge --info |grep ACCEPT ACCEPT_KEYWORDS="amd64 ~amd64" So portage is actively adding the amd64 stable keyword, based on the ~amd64 in make.conf. It has done so since at least whatever portage was around for 2004.1, which is when I started with Gentoo/~amd64. (As I switched from Mandrake Cooker for AMD64, I never even seriously considered stable Gentoo/amd64, and have run ~amd64 from day one.) As I said, if it didn't work that way for some package, there was a bug somewhere! Also note the wording in the handbook and the Code Listing 1.1 found here (link should be a single line, in case I forget to come back and unwrap this before sending or if it wraps on your end): http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml? part=3&chap=3#doc_chap1 >>> Generally I've always run stable and then never shied away from having >>> a larger set of file in my package.keywords file to get what I think I >>> want to run. >> >> With ~arch by default, you normally have very few packages listed in >> package.keywords. There /may/ be a few individual packages that you >> choose to stay with stable on, but at least here, I don't use >> package.keywords for that but rather, package.mask, and mask whatever >> individual version I'm having problems with, thereby forcing portage >> back to a previous version, whether that's stable or an earlier ~arch >> version. >> > i found out that is better to have a less long package.mask instead of a > long package.unmask. it's faster to controll the stuff in your pc. That sentence is rather difficult to parse, here. I think it's probably because English isn't your native language, right? See if the following accurately conveys your intention or if am I still confused? "I [have] found out that [it] is better to have a short package.mask instead of a long package.unmask. It's more efficient control of the stuff on your PC." If that's your intent, I agree. I prefer the shorter file version here myself. It's just simpler to manage. However you're not directly addressing what I was. Note that I was talking about package.keywords as opposed to package.mask, not package.unmask, which I didn't mention at all. I was suggesting that if one has ~arch by default and finds an individual package where one wishes to revert to to stable arch, it may be better to list the broken ~arch version in package.mask, thus reverting to the working arch/stable version, instead of using package.keywords to revert to stable. For one thing, masking an individual version only affects that version, not newer versions, and in the next round, it's quite possible the ~arch version will be perfectly fine. If one has created the entry in package.keywords, one will still be stuck with it for the next version, while if the individual broken version is listed in package.mask, the next ~arch release will show up as unmasked again, giving one a chance to evaluate whether the problem is fixed or not. Hopefully it is. In practice I don't end up using package.mask very much. Most of the time, if a package doesn't work, I check bugs and if necessary file one, but often someone already has a bug filed and there's already a patch available for me to apply. I'll normally do that instead of masking the package. And occasionally I'll leave an update unmerged for a couple days if it's broken, hoping either a further update is release or a patch appears on the bug (which I've CCed to if I didn't file it myself) that I can apply (in my local overlay or whatever) and then merge the package. If I put something in package.mask here, it's because it truly is broken on my config, perhaps because I often run hard-masked new gcc or baselayout/openrc versions or the like, before they even hit ~arch, or maybe because I tend to customize my system more than most and the package simply was never tested (even upstream) on a system that looked like mine before. In any case, I check for a filed bug and file one myself if necessary. Since that type of bug tends to take somewhat longer to fix than the trivial ones, if the package won't compile at all or has broken functionality I truly depend on, I'll package.mask that version and fall back to an earlier version until the bug is fixed, or in some cases I decide whatever customization I had that was breaking things isn't worth the trouble and I change it to something that works. So I usually have a very small package.mask. Right now there's only one entry in it, a permanent one, app-emacs/emerge, because one time I accidently double-typed "emerge emerge" and got /very/ confused when there actually /was/ a package called "emerge" and it tried to emerge it! =:^) So I keep that entry there to give me a warning I can understand (instead of a long list of new packages I didn't expect), if I ever make that mistake again. > if there's the lack of testing devs for going into stable i don't really > know if it worths to continue keeping this distinction. maybe it would > be better to have something like a hardened branch in which to go with > only stable and secure stuff that gets updated rarely but that can be > used as production system. more like the fedora red hat enterprise > approach, where red hat is very stable and not updated very often > if not for security reasons and fedora that gets the new stuff. Well, keep in mind what you're replying to was written by a guy (myself) who doesn't have much personal use for stable. Some people do, and I probably would too if I were running a production server on it. But... Gentoo really does /not/ have an "Enterprise class" stable branch. Every year or so the discussion comes up again on the dev list, and we've had devs try to start such a project, and devs leave when it didn't work the way they wanted it to. The problem is that supporting such an ultra- stable branch, backporting fixes to old versions instead of forcing upgrades, etc, requires enormous development and testing resources that Gentoo simply doesn't have, and as it's currently structured, IMO will never have because it's in conflict with the whole idea behind Gentoo, rolling updates and all. Honestly, while I'll straight up admit I'm biased, I don't really see the purpose behind a Gentoo (as opposed to say Red Hat) stable in any case. The idea of a compile-your-own, seriously customizable (USE flags, CFLAGS), rolling update distribution, fits very well the user that loves that sort of customization and control, and sees keeping up to date with the latest as a good thing. This is where Gentoo works best. But it doesn't fit with the user who needs long term support, who would rather keep a known working version and only change the bare minimum to get security fixes and the like, who often needs a one-size-fits-all less customized install (a known and predictable set of CFLAGS, a known set of dependencies that always apply to a given package, etc) so it's efficient for third party and proprietaryware (Oracle, for example) folks to support them, etc. That's the domain of the Enterprise distribution, and Gentoo's whole structure just doesn't fit. Now, it certainly WOULD be possible for a third party to create a Gentoo BASED Enterprise distribution, and that would be great! However, I'd argue that Gentoo itself can't do this, because it's antithetical to the very assumptions on which Gentoo is based, and were Gentoo to head that direction, it would by definition, lose those qualities for which it is known and which attracted many of us to it in the first place. So as I said, every year or two there's a big discussion on -dev about trying to force Gentoo into the Enterprise mold, and unfortunately, every year or two when it does, some devs tend to get disillusioned and leave, because the rest of the devs resist casting Gentoo in concrete like that, and as a result, it'll never be the big money big business distribution these disillusioned devs seem to think they want. But if they wanted that, my question is why they're working on Gentoo in the first place, when there's far better matches for that ideal. Let Gentoo do what Gentoo does best, and let Red Hat do what Red Hat does best. While we're at it, the same applies to the usual KDE/GNOME/XFCE/etc wars, and the VIM/EMACS wars, and ... and ... I've come to realize that the approaches are just different, neither one "better", altho certainly individuals will find one or the other "better" for their individual needs. But GNOME folks complain about the confusing array of configuration options available on KDE, and KDE folks complain about the crippling lack of configuration options and the "There can be only one best way and we know it" philosophy GNOME seems to have at times, and what few realize is that it's NOT a wasted duplication of effort, and that the GNOME folks wouldn't WANT the KDE folks there breaking their precious ONE BEST WAY ideas, and conversely, the KDE folks wouldn't WANT the GNOME folks trying to take away all those nice config options we like, so it really IS best they keep to their own projects, cooperating where they can of course, but still separate projects. And a parallel idea applies to VIM/EMACS, etc. Let each project do what it does best, and attract the devs and users that fit best, and let the alternatives continue to exist and flourish as well, so everyone finds a home that works for them, and nobody ends up breaking the already working just fine solutions others have developed for their own needs/wants niche. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
