~arch
January 29th, 2008There are only a few things with Gentoo that will irk me and that is when people say that its unstable. The reason behind this is that I work with an amazing team who its their primary goal to ensure that arch (notice a lack of ~) is as stable as it can be and that if you emerge any application it will just work. I will say that the team does an amazing job of that task. Beyond api changes that you will hit eventually with any source based distribution. Course our documentation team always seem to have an accompanying guide of how to resolve any issues you might run into as you make the move past that API change ready to go. The logical, at least to me, assumption is that most people actually run ~arch as their tree of choice.
I’ve got a few things to ask and hope you consider why this might just be so and some of the consequences that are caused by this.
Do you really need the latest version of hal?
Really, this is a serious question. Can you actually tell me the changes off the top of your head between the stable version and the latest development release thats in the tree? If you can then I can see you actually needing it.
If you can’t then why do you actually run unstable?
I’m curious actually. I don’t personally feel that I’m behind on anything I really want to be. I have on multiple machines with less then 10 packages that are ~arch. Of which I would say that all 10 packages can have stable bugs marked for them. I will in fact go put in the requests tomorrow for them so that others who don’t test anything will have a updated version that works perfectly to upgrade to. I’ve just pushed 10 packages from ~arch to arch potentially because those are the only 10 that I really had any reason to use a ~version of and knew the new features of. Now, packages that were “behind” as some people claim, just became current. It would also put the arch teams out of business in a lot of ways. If you notice, I’m all for putting myself and others out of jobs as odd as that might sound.
So please respond as I actually really want to know. I would think that this is by far the simplest way for someone to get involved with a minimal of effort on the end of the users and you’re still able to use the version of applications updated in a far quicker manner then the developer having to go hmmm this has been in the tree for a year and no bugs have been submitted..maybe it should go stable.
January 29th, 2008 at 10:54 pm
Well for hal in particular I don’t (although once upon a time I needed it on ppc
but it made its way to stable rather fast in that particular case - I happily tested it).
Do I always need the latest and greatest, well no. Except may be for a few select apps for which I will go as far as having my own personal overlay.
Really I experiment with stuff. Sometimes I want to try something new just added
to the tree and it kind of stay in package.keywords so its more a matter of house keeping with me. udept helps somewhat but has funny ideas about what should be on my
system (OpenOffice-bin instead of OpenOffice for example). And yes I should send
some of those for stabilization or in case of ppc, just keywording. Lazy, lazy me.
January 29th, 2008 at 11:15 pm
Some of the Portage documentation gives a bit of a mixed message about this. ( http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=3 : “If you want to use more recent software, you can consider using the testing branch instead.” ). It says “we recommend you only use the stable branch” but maybe not strongly enough?
I tend to run ~x86 versions of desktop apps which I know are updated regularly with new features (Pidgin, Amarok, Firefox, many others), even if I can’t name all of those features off the top of my head; but I use the stable versions of mostly everything else. Does this seem like a sane policy?
On the other hand, many stable packages in dev-lisp, for example, are so out-of-date in the Portage tree that you almost have to run ~arch versions. Stable versions of some packages appear not to have been updated since 2005 or 2006. So that’s about 20 packages right there that I have to use ~arch versions of.
I’d submit bugs to mark new versions of some of those packages stable, but I don’t really know what the process is. What’s the criteria for something going from ~arch into arch? Is it enough for me to use an installed package for a while without things breaking? Is there documentation about this? I looked around the docs on gentoo.org but didn’t find anything other than http://www.gentoo.org/proj/en/base/x86/arch-testers-faq.xml which is about arch testers and tells about setting up chroots etc. to test things, which doesn’t seem like what you’re talking about (or is it?). How do I request a package to be stabilized properly without cluttering up bugzilla with redundant crap and wasting devs’ time? These are the kinds of things I don’t know.
January 29th, 2008 at 11:35 pm
I’ve always been running ~ arches, both because I like bleeding edge stuff and because I don’t mind investigating broken builds and post bugs about it. Even unstable has been very “stable” to me, so keep up the good work!
January 29th, 2008 at 11:48 pm
Do I need latest hal? No. I am not even sure that I need hal at all. Do I use ~arch? Yes.
Why?
First, because I have less problems, then my friends using a arch+some unstable packages.
The blatant truth: a lot of (most?) problems I hit, will torture my arch using friends too. They ask me - I can help them, because I hit the problem earlier and have the answer. But sometimes they hit problems, I never had. And the main difference is, that I run a pure ~arch and they run an impure arch system.
The second big reason (after I hit the problem first, so I can help, I have less problems then they have), I am a version junkie. I like to have the latest KDE, xine, glibc, kernel, gcc as soon as it is unmasked. Even more true for games, where the difference between two releases can be huge. Like wesnoth. Every new version is a different game. And then there is stuff like nvidia-drivers, where the 169.XX drivers have huge improvements over the ’stable’ drivers. If I want stale, but stable, I could use debian.
And the third big reason: I am lazy. Setting ~amd64 in make.conf is way easier than putting 30+ packages in package.keywords.
So from my POV: you run ‘pure’ unstable or ‘pure’ stable and (mostly) everything will be fine. But if you start mixing stable+unstable packages you’ll run in problems. And since I am not the person to be satisfied with nvidia drivers from the stone age or elderly KDEs (hey, version’itis’ and bleeding edge where part of the reasons why I installed gentoo in the first place. Back in the 1.0 days…) I go the unstable path - and don’t complain too much, if something breaks. And since a lot of the breakage happens for my stable using friends too, I don’t even see a compelling reason not to use unstable.
(but don’t ask me for examples - I forget the problems as soon as they are solved. Until the next person stumbles upon them).
January 30th, 2008 at 12:10 am
Thank you all for your replies. Keep them coming as this gives me more to work with. Thinks like brians replies especially. Gives me a topic to talk about and possibly look into a General ways to help document.
Brian, I’ll be writing tomorrow to give you some details about how to go about requesting those packages be marked stable so that you can go about that process.
January 30th, 2008 at 12:50 am
I’m still finding with amd64 that a lot of normal sounding applications need to be unmasked to use them at all. No, I can’t offer an example right now (at work).
This issue particularly affects me when there’s a load of dependencies on a package I want to try, so not only do I run 1 package unstable, but then I have to unmask a load of others to get the correct versions. Then I’m in the situation, do I *really* need unstable HAL? Well, I genuinely don’t know because I can’t remember why I unmasked it (short of manually recording the dependencies against as a comment in package.keywords). I also don’t know what silently depended on it after I unmasked it.
Sometimes I go through and try to remove everything in package.keywords, then re-keyword just the things that cause breakage, but that’s boring and iterative so doesn’t happen very often unless I’m in an organising mood.
Also, when I’m trying a new unstable package, I’m never quite sure what version to unmask. I don’t *really* want to run unstable - it’s just that there’s no stable version.
So, the dilemmas: The version that goes stable could be a version prior to the one I’m using (I don’t want to downgrade and magically loose features). But I also want to get whatever updates are available, particularly as it’s unstable and is therefore more likely to be receiving important patches, so I don’t really want to unmask just that specific version. Also, if you unmask a specific version of a dependency, you’ve got to go back in an re-unmask it later, etc. But I don’t *really* want to keep on the bleeding edge running unstable for the rest of existence and would be happy to link down to the appropriate stable version when available.
Xeffects was a particular cause, however because I could copy/paste the whole block, I could remove all the unstable marks in one go. I suspect there’s a similar thing with kde4. I’ve started using portato which unmasks for you, however, I’m not entirely sure what it does with my package.keywords file.
January 30th, 2008 at 1:22 am
I generally try to keep my system as close to arch as possible (i use x86, amd64 and ppc(64) ).
But some of the packages I depend on are hopelessy outdated.. dev-db/postgresql .. the stable release is 8.0, 8.3 is in release candidate state… there is usually around 15-25% more performance for each major release (8.1 -> 8.2 -> 8.3) and lots of major features (new features for 8.3 is for example full text search, which is vital for my kind of work) …
Being a few point releases uncurrent is fine with me, but multiple major versions is just sad … I run around 50-60 packages in ~arch as a result..
January 30th, 2008 at 3:01 am
Regarding HAL:
Yes, I actually do need 0.5.10 (~arch AMD64) on my new Thinkpad, because it has some important changes merged in conjunction with new 2.6.24 kernel features. See the relevant Thinkwiki page, sections “Useful Patches” and “Optical drive”. Though supposedly steev was going to find a way to get an equally functional system without HAL whatsoever, so I’ll be watching his blog for reports from the non-HAL front.
And, well, things like Bluetooth are sadly neglected, so have to run mostly ~arch there.
Also for my laptop, the iwl3945-ucode. Sometimes running new hardware means running a lot of ~arch, which I’m still not comfortable with, but it’s the only way to get the most use outta my hardware. Heck, I’m going to have to use hardmasked Intel X drivers. Using that makes ~arch seem like a picnic.
January 30th, 2008 at 3:18 am
I must admit that i can’t name the improvements in hal, but yes i use ~arch.
Why? Because i like having the latest, and the few times things breaks, i find that it’s often caused by api change. And that i would hit running arch too.
Sometimes i found it even necessary to run ~arch or even overlay to get things to work. For example, my Thinkpad t61p with nvidia quadro fx 570m not even the ~arch drivers gave me 3d accelerating.
It does feel like ~arch is more stable now than it was 3 years ago, when it was even more ‘bleeding edge’. But that is just my feeling, i have no stats to back it up.
January 30th, 2008 at 4:00 am
On my server:
Stable. Only packages I need to be ~arch are that. Mostly this is in regards for SELinux where some policies is outdated, but it seems like Chris have not had the time to make it everything work as it should (is there any more then him working on SELinux?).
Only thing missing there is a working hardened toolchain containing GCC4, but that is another story.
My desktop is running ~arch. This mostly becouse I am toying with things like nouveau, and they have a tendency to need more current package then arch delivers (hell, some thimes I have had to make my own ebuilds or make SCM ebuilds to have things build/work.
I do not have time with breakage mostly becouse I know where to find fixes and where to report if there aren’t any yet.
January 30th, 2008 at 4:45 am
Sometimes it seems to take far longer than the recommended 4 weeks for something to go from ~arch to stable. This is what’s annoying, the users sometimes have no idea what to expect for when a package is supposed to end up as stable.
As Svenne has pointed out, there are some packages which are so far behind the official releases it’s rather poor for Gentoo. Instead of calling it the stable branch it should be called the stale branch!
Infact, I’d like to see a policy which ensures that ebuilds aren’t left in ~arch forever. I’m sure a script could be run on a daily basis which lists all ebuilds with ~arch keywords that haven’t been touched for 90 days (I’m sure someone did this in past, although it was buggy and listed new arches as having ebuilds untouched for 400 days). If there are bugs against the package which need fixing then I’m sure that a developer should be modifying the ebuild more than once every 3 months.
If there aren’t any bugs against the package and the ebuild is lingering then someone should look at it and consider stabilising it.
I know it isn’t a perfect suggestion due to dependencies and various other complications, but as a user I’m a little bit fed up of being told to use ~arch because the developers can’t seem to stabilise packages in a timely manner.
January 30th, 2008 at 7:45 am
I use ~arch and often development overlay and/or hard-masked for testing versions, mainly because I like the challenge and stimulation of the new, even when it means fixing things once in awhile. Computing is my hobby, not my job, so I can afford the luxury of that breakage risk, and I actually find the occasional breakage a challenge to trace down and work around or fix. Tracing down and fixing code that someone else has already fixed in a new version is about as fun for me as watching last year’s Superbowl will be for the average football fan — it’s history, done with, time to move on and make new discoveries; tackle new challenges.
Gentoo makes all that easy! =8^) After all, if I wanted a boring hobby, there’s always water to watch boil or paint to watch dry. =8^)
Also, some things I really want to run the new versions of due to new fixes and features, say KDE (yes, I know there are reasons and I’m not complaining, because there’s ~arch and overlays for me to run! =8^), are often way behind for stable, and as others have noted, a full unstable system tends to be less unstable than a partly unstable system.
Also note that I run amd64, where until fairly recently stuff like gcc, glibc and binutils simply weren’t as stable and mature on it as they tend to be on legacy 32-bit x86 — there were often DRAMATIC performance improvements and sometimes bug fixes between versions, and for someone willing to fiddle with gcc-config and etc when necessary, there were much larger rewards to running the newest versions than on mature platforms like legacy 32-bit x86. That has gone away to some extent as the platform has matured, but certainly thru gcc 4.1 and then 4.2 as it wasn’t the hassle some versions are, there were good reasons to use new versions for amd64, and I was running hard-masked and even beta-gcc versions (which would now be in the toolchain overlay, AFAIK) at times. Since those new versions often required new glibc and binutils to work, and new package versions of everything else were least likely to have issues with the new gcc and glibc as well, it just made sense to consistently run the new stuff.
Duncan
January 30th, 2008 at 8:11 am
First, my keywords.conf:
*/* ~amd64 amd64
app-shells/bash -* amd64
x11-themes/* ~x86
media-sound/aldrin ~x86
media-libs/libzzub ~x86
dev-python/pyzzub ~x86
net-zope/* ~x86
I run ~amd64 because I have found even ~ to be quite stable. When there are compilation issues or runtime issues I can spend 2 minutes to workaround them, either by forcing them stable or checking out the forums / bugs.gentoo.org . The only thing I run stable is bash.
Also there is a noticeable difference in speed and stability using ~amd64 over amd64, as the above poster stated.
January 30th, 2008 at 9:57 am
Why do I run unstable? It’s not to run the latest and greatest glibc and hal, I don’t care about system packages. I care about all the little stuff that developers never get around to marking stable, which are always small little packages. It’s the little ones where small tiny version bumps do make a big difference.
January 30th, 2008 at 2:43 pm
I’m basically running ~amd64 because one day I found myself with an accept_keywords file full of packages I had to unmask to get at all, their dependencies, their dependencies’ dependencies and so on. Actually, I’m very happy with ~amd64, it feels a lot more stable than amd64 did (although I suppose this can also be credited to the fact that I’ve learnt a lot since I was running amd64).
January 30th, 2008 at 3:02 pm
I run stable, I find the slight version delay acceptable given that the packages have been tested for longer.
Like Stive Dibb said, some packages don’t seem to go stable without me filing stablisation requests (doesn’t anyone else do these for packages I like?). I’m generally prepared to do that (it’s the only use I’ve had for my bugzilla account so far).
My packages.keywords:
net-misc/tor ~x86
media-fonts/fonts-indic ~x86
net-analyzer/snortalog ~x86
fonts-indic has a pending stablereq, and I need to file one for snortalog. I have tor as ~x86 because I want any security fixes/anonymity fixes asap.
January 30th, 2008 at 4:11 pm
I agree with Brian. I am not aware of the proper procedure to post bugs, so I don’t. Most of the time, I have “managed” to overcome most issues my self (thanks to the likes of the Gentoo Wiki, Forums and Google and Gentoo Dos’s - in that order). I have an _almost_ stable amd64 install (with the exception of the sys-kernel/suspend2-sources, nvidia-drivers/nvidia-drivers and a bunch of desktop apps and games) running on a brand new, untested notebook product. I have had surprisingly good results, however stuff like sound and the nvidia-drivers are still not working too well. How can I work with the Gentoo community to help iron out these bugs and push towards less ~amd64 masked packages?
January 30th, 2008 at 6:23 pm
Here’s what I have.
# I want to test the gamepad
games-misc/sdljoytest ~x86
games-util/joystick ~x86
# I live in org-mode
app-emacs/org-mode ~x86
app-emacs/calc ~x86
# This game rocks. I bought it.
games-action/lugaru-demo ~x86
# I’m a try dis
games-strategy/x2-demo ~x86
games-strategy/darwinia-demo ~x86
games-strategy/dominions2-demo ~x86
games-strategy/gorky17-demo ~x86
games-fps/warsow ~x86
games-board/megamek ~x86
# I’d like to play this, but it can’t work on my display
games-roguelike/scourge ~x86
# I want to use the latest vice because 1.17 is hosed
app-emulation/vice ~x86
# I’m testing this
games-server/crossfire-server ~x86
games-roguelike/crossfire-client ~x86
# Let’s make muse work again
media-sound/museseq ~x86
# I want a current flash
net-www/netscape-flash ~x86
# They killed XMMS without a suitable replacement!
media-libs/gst-plugins-bad ~x86
As a result of this post, I did prune out a few package/version combinations that no longer exist. My problem is that I find something I’d like to use that is marked unstable for whatever reason. I modify the files in /etc/portage enough to make the world start spinning again and then I forget to remove any hacks at a later date, unless something breaks me.
In some cases (like games) the packages seem that they will never be marked stable. I’d be half tempted to suggest just removing them since they seem to get no attention anyway, but that would be when I’d go looking for the door.
In other cases (like vice or liferea) the ’stable’ version was unusably broken at one time and the ‘fix’ was to move to a particular unstable version. I’m not calling this common, but it happens. Cleanup is less common since I never find out when the hack is no longer needed.
When I was more aggressive about trying to make my machine into a recording/midi workstation I had a lot more in my keyword file because pulling in package foo (let’s say aurdour or something) required a whole hose of other unstable packages. I made my life easier by giving up on using my system as a recording station. It would be even easier if I gave up on games, but then again, I’d have little reason to be using the system. Email and RSS are hardly a reason to use any particular disto.
Edd
January 31st, 2008 at 12:26 am
Thank you.
Not only is the never-ending “versionism” an inevitable feature of Gentoo due to the rolling updates, but it is also generally a problem in the Linux-world.
The “catch-the-patch-of-today” game is unfortunate in a situation where stability would be needed over anything else, be it Gentoo or Ubuntu.
January 31st, 2008 at 3:47 pm
dear drear. there are ’stability needed over anything else’ distros already.
SLES
RHEL
CentOS
debian
why turn gentoo, which always was bleeding edge from the very beginning, into another debian which is ridiculed by everyone because of their ’stabilitynim’ that turned into ’stalenism’ and at the end into ‘outdatednism’?
January 31st, 2008 at 6:31 pm
I don’t want gentoo to become debian. I jumped that ship after the stable release was like two years out of date and the organization was more interested in political games like what kind of balloting/election scheme can they devise to guarrent that an election will result in non-free repository being discarded.
For what it’s worth, I’m not really complaining about having to do the occasional ~arch to deal with a problem. I guess I’m more complaining that if it’s really that bad a thing, then why do I keep having to do it? Granted most of the ~arch stuff I’ve done was the result of testing outliners (because I needed to find a good one), playing games (which don’t really seem to get that much love in gentoo) and trying to use my system to record and sequence like I did a decade ago on Windows (which I’ve gave up on once again).
There was a time with a package like vlc or something like along those lines that I think required over 6 other packages with ~archs. That was annoying to work out. That’s when I was blindsided by the removal of xmms and I was trying to find something that could handle mp3s, oggs and all the formats that libmikmod could handle. I’ve had to give up and settle on rhythmbox with gst-plugins-bad flagged ~arch and just accept that the modplug plugin just can’t do everything mikmod can.
I’m not exactly headed for the door at the moment but I have been looking at the options. I guess if there was a distro that had better support for games, any real support for recording or maybe even if one had good support for the mikmod gst plugin in rhythmbox (which does have a much nicer media library than xmms or anything else I’ve used) I’d be at least tempted. What with all the giving up I’ve just realized I’ve done and all the articles I’ve been reading stating “We devs do what we want and if you don’t like it, that suits us just fine. Leave.” or something to that effect, I don’t know why I wouldn’t at least look.
If ~arch is really the bad, then it’s just something else I’ve done wrong in gentoo. Yay.
Edd
February 1st, 2008 at 7:09 am
“Can you actually tell me the changes off the top of your head between the stable version and the latest development release thats in the tree” No and why should I?
I am not a user of HAL (for this example) I am a user of applications that may require the latest HAL, and the changes for those apps I do use I can tell you the changes.
I would love to go ARCH, but it is easier to manage a package.mask (for the rare cases) then it is a HUGE package.keywords due to dependancies.
Not only that there are apps that are sitting in ~ARCH that arn’t going stable by dev’s (ghdl for instance) even bug to update ebuild to make it amd64-friendly isn’t pushed through
so it is a bigger issue then just users wanting the latest and greatest
Sure make ARCH stable, but ~ARCH should exist for users who want to try try out new packages. Users trying out new packages are good source of bugs so said packages can go stable
February 1st, 2008 at 8:15 am
I run ~amd64 on my desktop computer and (mostly) x86 on my laptop.
Do I need ~arch? Most likely not, at least not on more than a few packages. Do I want ~arch? Depends. I like to try stuff and play with it, that of course includes new versions of software. As probably most users do, I do not really care about the version of a library, but I do care about the applications. Besides, back in 2004, one was missing quite a lot of stuff if one ran amd64 instead of ~amd64.
Yes, ~arch seems to cause more problems than arch, but if I sum up the time needed to fill (and maintain) my package.keywords on arch, add to it the time needed to investigate special arch/~arch mixture problems (like broken spell checking unless using an ~arch version of a dictionary) and compare that number to the time I invested to solve problems on ~arch, the advantage of running arch is somewhat diminished. This is especially true due to sometimes wanting the newest version: kde<4 comes to mind, I have not found a good reason to wait for those until they are keyworded stable. And then there is the software that just is not keyworded stable. Not to talk about packages that were not bumped since 2004 and thus horribly out of date and thus not in sync with the documentation on the web. I hit that problem with parts of latex when I had the least time to investigate those problems, being close to the deadline for my thesis. So sometimes running arch turns out to be a problem not by not knowing what features the new version has, but by not knowing that an installed version misses some vital features, beeing far outdated.
And since I do have a fallback mechanism (my laptop) if my “unstable” desktop breaks, I have not found enough reasons to run arch instead of ~arch on my desktop. Especially given that running half the system in ~arch and the other half in arch usually gives you more (and less documented!) trouble than just running ~arch.
February 3rd, 2008 at 1:19 pm
I run “~arch” ever since I use gentoo which is something about 5 years now. Why ?
I like the idea of having new(est) stuff und investigating if it breaks und possibly help others. If I wanna run stable I could use Suse or something similar (which isn’t that stable too IMHO). For me running “unstable” is somehow connected with using gentoo. Being able to use newest stuff makes gentoo interesting for me.
March 2nd, 2008 at 6:26 am
I’m mostly with the version-junkie, I-don’t-mind-if-it-breaks-a-bit and I-like-to-help-debugging crowds. But there’s another thing I’ve noticed. By debugging, I learn(ed) a lot about how some packages work specifically and what “nice” pitfalls Linux development has in general. One of the first things I’ve learned about was how -fPIC isn’t quite as simple a story as it might seem. Flameeye’s blog helped a lot there, too.
Oh, and I got roped into er convinced of being arch tester by all this. For alpha
Though I try to be of help to all arches I use (x86, amd64, alpha) and in a general way.