Beso <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Tue, 25 Nov 2008 23:19:40 +0000:
> 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. Yeah, that could do it. Not a problem... except that it wasn't until I actually started trying to deconstruct it as part of my reply that I actually made sense out of it. Before that, I thought it internally conflicted with itself and figured I knew where you were trying to go with it, but wasn't quite sure. Even afterward I wasn't sure I had it right, thus bringing it up to ensure I did. ... And while I don't understand more than a few words in any language other than English, I'm /usually/ pretty good at groking strange word ordering and etc, because I've been exposed to quite a variety of multiple cultures of /some/ sort or another (plus now archaic English) most of my life. So I'm unaccustomed to not being able to make sense out of things, even if the word order is /not/ customary English. But this one I really did get wrong at first. It was a stumper! > 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. Yes. I've only had that happen a relatively few times, because I only use a relatively few overlays. And when it did happen here, it just seemed to work the way I needed it to anyway, so I didn't trouble myself with it. But certainly, once someone's running more than a small handful of overlays, it can get "interesting". > this is one of the reasons that i've switched to paludis That's one thing the paludis devs have gotten right. It was designed pretty much from the beginning to handle multiple overlays and make configuring which one gets used for which packages relatively easy. > 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. I used to do a lot of personal overlay stuff. Now, I use Ed Catmur's portage-patches scripts, which hook into portage and allow one to apply one's own set of patches to a specified package. It works for patching with an /etc/portage/patches tree much like the /etc/portage/env/ tree that the last few versions of portage have worked with for setting stuff like CFLAGS in a package-specific way. (I only recently realized Ed Catmur is the author of udept, which I had merged previously, so he / should/ be relatively familiar with portage tricks.) Since I installed those scripts and now use package.keywords to set ~x86 or whatever for some packages instead of putting them in the overlay and adding ~amd64, my personal overlay has remained almost empty. I had a "live" pan ebuild, but [EMAIL PROTECTED] encouraged me to forward it when I mentioned it in a bug and it's now in the tree. I have a copy of the amarok-1.4.9999 live ebuild that I needed to modify to install slotted and not conflict with the amarok-2/kde4 version, but that's about it. If the patch is to the sources, I use portage-patches and use the existing ebuild without changes. Only if the ebuild itself (or eclass, but that hasn't happened in awhile) needs patching, and it can't be handled by say setting EXTRA_ECONF in the /etc/portage/env tree either, does it end up in my overlay. And that doesn't happen so often. Usually it's a sources patch, and that can go in the /etc/portage/patches tree, thanks to Ed's portage-patches. > 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 Hmm... I've been using --as-needed (in LDFLAGS but not forced in spec files) for awhile myself, but haven't seen my bugs ignored with it. Maybe it's the type of bugs I file, or the type of packages I end up finding bugs in and the devs that maintain them, or the fact that if I think my custom LDFLAGS (or CFLAGS or still masked gcc version or ...) are causing problems, I set them to accepted Gentoo defaults for that package using a file in the /etc/portage/env tree, and specifically mention in my bug whether that changed the result or not. One thing's for sure, I've certainly developed a much thicker skin over the years, since one of my originally filed bugs got marked INVALID for some stupid reason. I don't just tuck my tail between my legs and go home like I used to, tho I've not had occasion to get into a real bug- status war since that changed. But my bugs don't generally seem to be ignored, either. Some don't get action for awhile, but it's not ignoring, it's the "real life" of the assigned dev, and the fact that some of my bugs are rather esoteric, so not /that/ system life threatening to anything. But Flameeyes' campaigning on the --as-needed thing is certainly needed. I'm very glad he's doing it, as it's something few would have the skills to tackle, but at the same time, something he can let his new machine do much of the work on, so maybe he doesn't overwork himself so much. Gentoo's lucky to have someone that talented around, and he doesn't have the enormous ego problems a lot of the similarly talented devs seem to have. Unfortunately, like my dad and sister, he seems to be a workaholic. They do great and wonderful things, certainly, but they they burn the candle at both ends doing it, and their health suffers as a result. Having that problem in my own family, I recognize it in Flameeyes as well, and his frequent hospital trips at such a relatively young age concern me. He's an asset not only to Gentoo, but to the FLOSS community in general, and I fear we're going to lose him if he can't learn to pace himself. Fortunately, he seems to have realized that himself, now, and has cut back substantially from what he /was/ trying to do. > O_O i didn't know that there was a package named emerge... I didn't either... until then. But I learned! =:^) > 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. Maybe the next time someone brings up the Enterprise Gentoo idea on the dev list, I should counter with the dropping stable idea... AFAIK the last time it came up was early this year, so it should be time for it to come up again sometime between this spring and next fall... But they've already dropped stable keyworks on IIRC mips (but don't quote me on that, it may have been a different arch, and I'm too lazy to go check my devlist archives ATM), because it just wasn't happening, and maintainers were getting seriously annoyed due to having to keep outdated and broken packages in the tree as the only stable on that arch. > 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?! Yes. But the problem tends to be that these Enterprise users need support, and for that to be economical, there has to be a reasonably large size group on the same packages built with the same set of options and CFLAGS. They can get their support and run their proprietary packages, but to do it, the tradeoff is that they gotta accept being a clone, one-size-fits-all. The hard economics of the situation are that as soon as you optimize for the hardware you're actually running, and build for the dependencies you actually need, you're in a niche that's small enough it's simply not economical to support you... at the level of commercial support that RHEL's customers demand anyway, or they'd be elsewhere. Practically speaking, you and I know that in many, perhaps most cases, the benefit of such "support" is highly questionable anyway, because practically speaking, posting to the relevant list/newsgroup/forum gets an answer way faster than paid support is likely to. And in the cases where it doesn't, paid support may fail as well. And... being open source, for the few cases where that paid support does actually mean a benefit, it's quite possible a single-shot consultant or developer job could be funded to address that specific issue, customized solution, for roughly the same money but in less time than than the paid support. But regardless, that doesn't provide someone else to point the finger at and save someone's a**, and... practically speaking, RHEL DOES pay a lot of paychecks for full-time FLOSS developers, that would at best be part time if it weren't for /someone/ deciding they needed that sort of support enough to pay the big bucks for it. > 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?! xorg is an interesting problem, not in the least because it has a very clear yet politically unpalatable solution, simply ignore users who chose hardware vendors whose only real competitive features are only enabled by proprietaryware drivers. nVidia, and to a lessor extent ATI but that one's being solved as we speak, are, simply put, holding xorg development hostage to the rate at which they develop their proprietary drivers to match. The logical thing to do would be to let xorg development and those user who have hardware with freedomware drivers continue their progress apace, and let the nVidia users be stuck on the two-years- outdated or whatever proprietary development model they've chosen to support with their buying dollars. Actually, if you look at it, that's gotta be one of the reasons Intel is pushing xorg development so hard. It has a competitive advantage in that it's hardware, while not as full featured hardware-wise, has native driver support for the latest whiz-bang xorg features right off the blocks, leaving the proprietaryware folks sucking dust, and it's not above trying to exploit it. AMD, who needs the Linux users far more than Intel does, was facing the very real prospect of being practically locked out of the Linux market due to Intel's Linux cooperation, and had no choice but to respond, first by buying a graphics maker so it wasn't locked out due to the proprietaryware actions of third parties, and then by opening up ATI's graphics to the same extent, or actually even further, pushing Intel. But the gamers and their preferred nVidia proprietaryware are continuing to hold things back, at least as far as stable support, and not just for Gentoo. All of the big distributions are facing the problem, as are Dell, Acer, Asus, and other OEMs now shipping Linux kit in some volume. No major distro can afford to cut off the nVidia user market share, so none of them can afford to ship a new xorg no matter how far behind their current version is, until nVidia deigns to support a newer xorg with their proprietary driver. And $deity have pity on the poor distrib that has the luck of having nVidia release a driver just after they've frozen the repository to all bug bug fixes in preparation for a new release, because now they'll be shipping with an outdated nVidia driver AND xorg, and can't really upgrade either one except as options, without delaying release another month or two to test the new xorg with everything. And if the major distros can't ship it, then the OEMs basing their own distribs on them can't ship it, even if they're using Intel hardware that could really benefit from the newer xorg. Fortunately with the AMD purchase of ATI and its subsequent switch back away from the dark side, 2009 seems likely to resolve this. The distributions and hardware OEMs both are getting increasingly impatient with nVidia, and with Intel support right there and AMD/ATI/Radeon support coming on fast, 2009 looks likely to be the year nVidia either reverses itself as well, or regardless, starts losing its ability to hold things back. Bringing that all back around to our discussion at hand, for other distributions, that'll probably mean shipping a more modern xorg, with an optional stale xorg just to support nVidia users, and a * on their feature list with an "nVidia users" small-print disclaimer. KDE's not a distribution, but it has already taken that tact by choosing not to support nVidia proprietary driver users at full feature strength some of the time. Gentoo... will probably either end up taking a similar position with stable, telling nVidia users to mask the newest stable until nVidia gets off their a**, or will continue to let stable xorg molder, updating it only when nVidia deigns to allow it by updating their proprietaryware, meanwhile forcing more and more users who want decently current features to either highly package.keyworded systems, or to fully ~arch systems. Hopefully either nVidia or their proprietaryware driver users get a clue, but I'm not holding my breath... > 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. KDE... has been a problem for Gentoo of late. Well, KDE4 has been a problem for everyone, not just Gentoo, but Gentoo had problems before that, as you mentioned, from 3.5.x. The real problem for Gentoo has been the size of KDE... and the devs on the project. Losing developers, and before their loss, loss of cooperation with the rest of Gentoo, due to an inability to work well with others... hurts any project. There are certainly two sides to the story and I'm not close enough to it nor do I have any desire to pick sides, so I won't, but the fact is, whoever was to blame or whether it was just the way things had to be, that loss /hurt/. We're lucky a bunch of users got involved in the overlay work, or Gentoo basically wouldn't /have/ a modern KDE, either 3.5 or 4.x series, at this point. Hopefully that's all behind us and KDE can become a thriving healthy project once again. As I said, I'm a bit far from the action, but that influx of new blood, as well as some developers from other areas putting on another hat, has seemed to help, and the major teething problems with the switch to the 4.x series seem to be over, so I'm optimistic. Otherwise, much as I hate to since Gentoo otherwise seems about the ideal fit for me personally, I may end up having to ultimately switch to something else (assuming KDE4.2 finally gets the kde4 act together upstream, as they've been promising, or maybe kde will be what I end up dropping), or perhaps more likely, simply switch to kde upstream directly for KDE stuff. But none of the other really big projects seem quite as bad as Gentoo/kde and Gentoo/xorg. In particular, toolchain seems to still be quite functional, and the PM side is strong enough it's supporting three thriving PM! What about GNOME and XFCE? I've not /read/ of anything so majorly wrong with those projects and from outside, they've seemed much smoother, but unless GNOME reverses course with gnome3, it's not for me, and xfce... well, I guess I've never seriously looked at it, but I've always thought of it as not as full featured as I like... and my hardware certainly isn't the issue it seems to be for a lot of xfce users. For everything else, at least for desktop use, it doesn't seem to me that stable lagging a bit should be a serious problem. If someone needs codec support only in a new media-* package, unlike xorg or toolchain or the desktop environment, they can package.keyword it without threatening the stability of either the computer itself or at least their entire desktop. >> 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. > 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. Exactly. Especially when "progress" as defined by some is "regression" as defined by others. When that's the case, as it is for example with the proliferation of user accessible controls on KDE as compared to forced conformance to the "One True Way" (tm) on GNOME, it's /better/ to have separate projects, and far from hurting each other, they keep the devs who might otherwise cause problems and needless infighting on the other alternative, working on their preferred alternative instead. Where it's possible and convenient, they can always cooperate, and freedesktop.org has been very good at bringing that with its various hosted projects, while letting the desktop projects otherwise pull in their opposing directions without hurting anyone, and in particular, without hurting the interests of the wider FLOSS community. Why so few see it and calls for "One True Desktop" (tm) are so common, I don't know, except that those folks must still be thinking the "One True MS Way" (tm). > 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. Some people like the security and comfort "Big Brother" (tm) provides... I could go off on a US political tangent here, or for that matter, on a big bad MS tangent, but I won't... The big bad nVidia bit above is enough for this post. =:^) > 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. That's what's nice about choice and the FLOSS community way of developing a bunch of competing solutions in parallel. That cross-pollination is not just allowed, but actively encouraged! =:^) > 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. Of course, the Boycott-Novell folks have a very different view of things there. But fortunately for me, I've been far enough away from that I've had no need to develop an informed opinion on it. I very seldom have to deal with Office formatted docs of any kind (save for the usual .pps cute/ funny mail stuff making the rounds, and I just ignore that), I don't use Gnome for other reasons and haven't had to deal with mono, and Gentoo's sufficient for me so I've little interest in Novell/SuSE as a distribution. So I've sufficiently few dealings with them or their controversial products that a boycott really isn't something that would affect either them or me. The work of Greg KH (Novell employee, AFAIK) on the kernel is about as close as it gets, here, and evidently his integrity is sufficient I've seen nothing calling that into question. -- 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
