2008/11/25 Duncan <[EMAIL PROTECTED]>: > Beso <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted > below, on Tue, 25 Nov 2008 12:16:56 +0100: > >>>> 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." > it has been written in a hurry at work, while speaking at the phone with an italian customer... so i've spit out a rather difficult to understand sentence.
> 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. > same as before... > 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. > this works for packages in gentoo. the problem is when the same package is provided in other overlays. I tend to use quite a big number of overlays and in that case the package mask is mandatory when you want to mask a specific version and overlay. sometimes when the version is the same this is proving difficult with portage. this is one of the reasons that i've switched to paludis long ago when masking a specific package from an external overlay wasn't really simple (if the version was the same of the one present in portage). > 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. > this also applies when i want to mask/unmask stuff from my personal testing overlay (mainly patches against some build that fails). also when using masked ebuilds, like the live ones, the use of package.unmask and sometimes package.mask is quite useful. > 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. > my problem is that my bugs are ignored due to --as-needed. now that diego has started to massively test the --as-needed flag as default maybe would be useful to go back reposting bugs that i might find. i'm now curently undergoing a full system backup and automatizing it via rsync and cron and after that i'd recompile whole world with forced --as-needed and --no-undefined and i expect quite some issues with kde4, since i still haven't understood if xmlrpc-c is really broken. so i need a backup of a fully working system before undergoing this recompile. > 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. > O_O i didn't know that there was a package named emerge... >> 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. > well, this also applies to the stable branch. then there are also the keyworded packages. i know that when gentoo came out this distinction (as it is still now) it has been a really good one, but still, nowadays when the unstable branch is as stable as the stable branch, with a big lack of devs, maybe it's better to think of dropping one of the 2. > 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. > it's simple in my opinion. rhel offers a big stability with a lot of security features and so on. but it has a downside: it's built on classic and not optimized flags and the packages that are built are fully built, and not only with the stuff you really need. having a branch that has similar features, but it's optimized for a specific machine and takes full potential from that machine would be a boost. don't you think so?! > 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. > then we're back to the point when the distinction between stable and unstable is still a little useless nowadays. the release time between one version and the following is going to decrease as time goes. an example is xorg. just think of how many xorg-server versions have been released recently, and from what i've read the project would be pushed farther form intel that wants a fully featured and working environment for professional use. which has been the latest stable xorg ebuild?! or for kde 3.5.7 and superior serie. the time in which it went stable has been very high. and the same reduction in time between releases is happening for other projects as well. i really think that this stable/unstable division should really be revised, especially when there's a problem with the lack of testing devs. > 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. > well, i'm not into starting a flame war for this, but in my opinion is more sensate doing something similar than continuing with the stable/unstable distinction, that in the last period doesn't really apply anymore. > 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. > well, it' s better to have a choice and a battle between them than having one solution that doesn't progress, or that progresses in a bad way, as happens on windoze for example. > 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. > i do agree with this point, but sometime it's better to have some arguing about new solutions and to try them out. you can always learn something new. as a little example, i have a friend that is fully convinced that linux is not capable of doing what windoze svista would do. i just showed him kde4 with compiz enabled, put on wow on codeweavers (thanks to the free giveaway offer from some time ago) and installed the native enemy territory and he remained stupified. he didn't believe that he could do the same things that he could do on windoze in a better way and more intuively on linux. now he's still staying with his windoze but he doesn't pretends anymore that linux is bad and not working. the same could apply for gnome when speaking of innovative features, or to kde when speaking about eye candy or too much innovation all together. everyone should sustain their ideas and show them to the other part so that the other one could learn something from it. and i think that when this happens everyone gets stronger than before. the same discussion might apply for microsoft-novell agreement that is has bought a very high compatibility with office documents to openoffice 3, so that everyone might continue to use whatever he likes without really worrying that the others could or couldn't understand them. -- dott. ing. beso
