that infernal stable/unstable portage masking thing

UnderDog138

Disclaimer: Correct me if I'm wrong (nicely please

)

Portage is what drew me to gentoo first of all, since I came from FreeBSD and its nifty port system. After playing with portage awhile and reading about it, I noticed it treats packages just like any other distribution does. Let's say Mandrake 9.0 comes with KDE 3.0.3 (which it does), because that was the latest stable release at the time the package tree was put together and finalized before 9.0 was released. In order for you to get the latest stable release of KDE (3.0.5) or the latest beta (3.1-rc5) you had to download the source or binaries from the KDE website and install it yourself. That's where ports came in handy with FreeBSD. If a new version of a program was released, there it was, right as rain, in the ports tree on FreeBSD and you could tell what version it was by looking at the distinfo file in the app directory in the ports tree. Often it had devel versions next to it, named app-devel perhaps in the ports tree. You could choose from the latest stable or the latest devel version.

I thought this was the case with gentoo but it seems like it's not. For instance, using the stable setting, portage still lists the latest stable build of Mozilla as 1.0.1. The ebuild for the true latest stable release, 1.2.1, is in there, but it's masked and can't be built. It's as if it bases the "latest stable release" version off the latest stable version that was available when that current gentoo version was released. Is this not so?

As far as I understand it, if I want to build Mozilla 1.2.1 for instance, I have to set portage to unstable to unmask all those ebuilds? If 1.2.1 is the latest official stable build, why doesn't portage reflect this? Why does it still say 1.0.1 is the latest stable build when it's actually not?

I think the portage system ought to unmask everything except what are considered unstable development versions, and let us build the latest officially available stable release ebuilds by default. That way, what portage says is the latest stable release, actually is the latest stable release, like the FreeBSD ports system.

If all this is wrong, I apologize for wasting your time. This is just my reaction to using Portage for about two weeks and wondering what the deal is with all these old versions of programs being considered latest stable releases.

And yes I did an emerge rsync first to make sure I had the latest portage tree. I'm not a complete idiot, although I may sound like one.

_________________
Adopt an unanswered post today!

bpkri · Posted: Mon Dec 09, 2002 1:03 pm Post subject:

Did you ever consider that not a software itself, but also the ebuild might be broken or cause problems? I do not know if this is the case with mozilla, but I have seen it. The ebuild tries to automatize the compile process, maybe applying patches, often applying configure settings. Things CAN go wrong there.
Even if they don't you have a lot of packages relying on another version of a software and you will not know if everything works as it should, when you use a newer version. So I think it is okay, that mozilla 1.2 is still not marked as stable.

psharp · Posted: Mon Dec 09, 2002 1:04 pm Post subject:

zhenlin · Veteran Joined: 09 Nov 2002 Posts: 1361

What the almighty gentoo developers consider stable is rock solid stable apparently.

bpkri · Posted: Mon Dec 09, 2002 1:11 pm Post subject:

UnderDog138 · Posted: Mon Dec 09, 2002 1:21 pm Post subject:

In other words, it incorporates the stability of every dependency it wants to compile into whether the entire port is "stable?" I noticed mozilla 1.2.1 wanted to compile another package which was masked. I went to that package and tried to just emerge -p the package, and it wanted to build an older version of the package. I emerged the newest one with no problem and emerge -p'ed the mozilla 1.2.1 package again and it said it could build it.

So even if mozilla 1.2.1 is stable by itself, the other libraries and applications listed in its dependencies must also be considered stable (and therefore unmasked) to be able to build the entire thing? That makes sense I guess, and if that's true, it raises the question of when will mozilla's 1.2.1's dependencies become "stable" so that mozilla 1.2.1 itself can become "stable" and be able to be built or upgraded with a simple emerge mozilla command?

It seems like we trade availability of brand new stable releases for stability if we have to wait on every dependency of a big program to be unmasked before we can unmask the big program.
_________________
Adopt an unanswered post today!

rac · Posted: Mon Dec 09, 2002 7:32 pm Post subject:

I equate "unstable" with "likely to cause reports of known bugs". Sometimes things get marked unstable because of things that depend on them, too, not just the other way around. Mozilla 1.1 was masked for a while originally, and a comment in packages.mask said it was because galeon couldn't be built with it at the time.

So although I understand your frustration, and remain hopeful that new features in Portage will soon make it easier to mix stable and unstable packages, I want to make it clear that the concept of "stable v. unstable" is not set in stone at any arbitrary versioning deadline: it fluctuates constantly. It's just that the notion of when something is considered "stable in Gentoo" lags a bit behind when it is considered "stable in a vacuum".
_________________
For every higher wall, there is a taller ladder

UnderDog138 · Posted: Mon Dec 09, 2002 9:00 pm Post subject:

That makes a lot more sense. A chain is only as strong as its weakest link, so in effect, a program is only as stable as the dependencies in which you use to build it. I suppose that philosophy makes for a very rock-solid portage system.

I wish I had understood this concept before I went and ranted about it. Thanks for clearing that up for me.
_________________
Adopt an unanswered post today!

jjares · n00b Joined: 28 Nov 2002 Posts: 17 Location: Argentina

try
emerge /usr/portage/net-www/mozilla-1.2.ebuild
The masking packages (as i see it) only protects you from automatic changes... but you can force whatever changes you need

Pigeon · Guru Joined: 21 Jun 2002 Posts: 307

Another problem with mozilla 1.2.1 is that galeon can't be built against it. (yet)

Emerging a masked ebuild won't work, FYI- masked protects both automatic and explicit changes. You need to actively unmask it first.

rac · Posted: Tue Dec 10, 2002 2:59 am Post subject:

max_colby · Posted: Tue Dec 10, 2002 3:13 am Post subject:

By definition, Mozilla 1.0.1 is the lastest stable mozilla release, while Mozilla 1.2.1 is the lastest stable developer release. Although it is recommended that most users use the 1.x branch (because it is very stable, and includes a number of improvements), the 1.0.x branch is maintained as the stable branch because Mozilla is also used as a development platform.

Having said that, it would be nice if a keyword in make.conf would make portage default to the 1.x branch, rather than the 1.0.x branch of Mozilla. ACCEPT_KEYWORDS could also be used for other related purposes: defaulting to the Apache 2 branch, rather than Apache 1, defaulting to Gnome 1.4 etc. I'm not sure if such behaviour would be helpful to anyone, or if it just creates clutter.

Pigeon · Guru Joined: 21 Jun 2002 Posts: 307

ibrandt · n00b Joined: 13 Sep 2002 Posts: 24

Well I just did:

des · n00b Joined: 01 Aug 2002 Posts: 7

rich0 · Developer Joined: 15 Sep 2002 Posts: 161

That tip worked quite well for me. I had been unmasking the mozilla 1.1 ebuild, but it would be overwritten every time I emerge rsync'd. Then emerge -u world would downgrade me back to the "stable" version. I essentially copied the mozilla directory to a local portage tree so that it wouldn't be overwritten, but that was a non-ideal solution.

Of course, what this solution doesn't help is when the next security patch for mozilla rolls out and we don't get it because it is masked. Guess I'll have to keep my eye out for that...

ibrandt · n00b Joined: 13 Sep 2002 Posts: 24