Since a couple of portage versions we got KEYWORDS="~arch" for "unstable but not broken" packages.
So why is gimp-1.3 still mentioned in package.mask?
gimp-1.2 is _really_ old and I suppose most people using gimp _want_ to have gimp-1.3, especially if they do have a "unstable" system with ~arch.
Additionally, gimp-2.0pre is out so gimp-1.3 really is not broken any more.
(reassigning to gnome herd :) )
I am using the 1.3 series since it got added to portage.
As he said. Gimp 2.0pre1 was released today, so I also vote
for putting Gimp 1.3.x to ~arch and adding 2.x as ~arch + package.mask.
Svens idea is probably not very good (hard-masking 2.0pre and unmasking 1.3.x), because gimp is in a freeze and 2.0_pre.. contains only fixes compared to 1.3.23.
So if we want to unmask newer gimps, we should use the 2.0_pre-versions.
But beside that I expect 2.0 to come very soon, so maybe we can just wait for that.
> adding 2.x as ~arch + package.mask.
Is gimp-2.* really a broken package?
gimp-2.0 is just a minor update to gimp-1.3, so why mask it? I am not a dev but I really hate when packages are masked just to be sure that it cannot lead to any kind of problem. There are many users out there who _want_ to have the blleding edge programs. That's what I think of ~arch. I want those newest apps without having to unmask them manually. The mask of gimp-1.3 is a relict from times when there was no ~arch keyword.
Anyone who doesn't want to take care about possible problems should not use ~arch. If you put it into package.mask, where will you get bug reports from?
I think gimp-2.0 should _only_ be masked if there are known issues that make it unusable on many systems. I don't think this is the case.
Yeah, IMHO, the .mask file should be used only for broken or being-worked-on ebuilds. Unstability in the program itself should be reflected in the ~arch flag.
what about a gimp-devel package?
What would be the advantage of a gimp-devel package?
Is anybody out there using ~arch who does not want the newest gimp?
Personally, I think using ~arch means that there can be problems anywhere. gimp-1.3 did not cause problems on my system for many months now (since I started using it). What's the disadvantage of normal gimp-1.3/2.0 in ~arch tree?
I don't like the idea of any completely separated devel-versions, because it's not necessary. I don't want to know if it's a devel version or not, It has to work (most times) and it has to be the newest bleeding-edge technology, I don't like reading about new features that I cannot use. ;-) What's wrong about that?
If I had a business depending on full-time working software environment, I have to use stable distros and not ~arch.
After thinking again about it, Hanno's idea (#2) is better.
If we do it like this, latest arch would be 1.2.x and latest ~arch 2.0pre1, correct? Sounds good to me.
That's what I said, too! ;-)
This is what I would expect from unstable vesus stable (arch called stable and ~arch called unstable).
why didn't spider ring in here yet? He probably got all mad about the misconceptions here. :)
The whole discussion here is based on the wrong assumption that ~arch means unstable packages. ~arch means testing of ebuilds, it is not a meant to put known unstable stuff in the live tree. Very common misconception, but hard to eradicate.
With that said yet another time, my plan in this was to remove the 2.0_prex version from p.mask when the ebuild is as good as i want it : there will be some fixme's noted in the current ebuild (will add soon), feel free to add patches for those to bugzilla. Since it can be parallel installed i see not much harm in exposing it in this stage to ~arch users after that.
And Bernd, pushing your personal bleeding-edge'ness on every Gentoo user out there is no reason to mark it available to me. Just as the function of ~arch gets misinterpreted a lot, Gentoo's bleeding-edge nature does as well. Gentoo is about providing the latest _stable_ packages in a distro (vs. eg. Debian where stable = ancient), not about providing every alpha/beta version out there for the few geeks who want a non-working system.
To close, marking this INVALID, because gimp-1.3 certainly should be p.mask-ed in general.
I never really understood this concepts of p.mask and ~arch and as time goes by I begin to think there is some kind of misconception in the Gentoo masking idea. I really know that this is the wrong place for a discussion like this but I don't know any better where I can be sure to get a competent answer. ;-)
From a user's point of view, putting ACCEPT_KEYWORDS="~arch" in /etc/make.conf is very easy and I will do this every time I install a gentoo box for my needs because I am a user who wants bleeding edge software.
Putting individual packet names in p.unmask is really hard to maintain for a whole system.
What you said is that p.mask is for unstable programs and ~arch is for possibly not working (testing) ebuild files, right? So what benefit would a user get if he accepts ~arch keyword? Nothing but trouble because of not working build processes.
As I first header about ~arch (when it was introduced), I never got a good explaination of this but It seemed clear to me that this means that bleeding edge software will no longer be completely hidden from non-devs (that's what p.mask really does) but will be available to users who set accept_keyword=~arch.
After some really funny discussion, it seems to be vice versa and the keyword-thing should be just for devs to be able to test more broken ebuild files and regular users should never benefit from this.
Don't you think there is something wrong with this?
I do not push my bleeding-edge'ness on every gentoo user, but I think it fits on many of them. There is that keyword thing and It makes it possible to satisfy both, users like me and users that want stable apps.
On the other hand, there's no distro out there that is so flexible about new versions like Gentoo. One single copy command is all you have to do when new (minor-)version are released. So technically, Gentoo is the very best distro to get bleeding-edge software. Additionally, the local compile process makes it a lot more flexible about libraries and so on because configure detects the present versions. This is one of Gentoo's great features and I wonder why this always gets blocked by some devs. If you have multiple keywords to separate, why do you want to keep all users stable? Why is there no way to get those (existing) ebuilds to be installed without putting a line for each packet in p.unmask?
This is indeed not the place for this discussion and actually there have been discussions on the mailinglists on this subject. I will explain in more detail some questions asked, but after that i really like to close this bug. I really feel like i'm repeating myself endlessly here, all these things i have stated before in other places (eg. mailing lists) & the general policy on this is in the documentation on the website (developer policy iirc).
@ 2nd paragraph : There is little gain for the user, besides running really the latest of latest in stable packages. Besides that, ~arch users help the distro by testing new packages so we can find bugs before something becomes declared stable. It's a buffer to filter out problems you don't want in a stable tree. ~arch shouldn't give much more trouble than stable arch, ~arch should be buildable at any time.
@3rd & 4th paragraph : wrong assumption, ~ was never meant as a way to expose unstable upstream packages to the users.
@5th : You still don't get the concept of ~ : if we use it as a means to provide upstream unstable/development packages we lose it as a buffer between a stable and testing area for a STABLE distribution. And for those users for whom the latest and greatest in stable releases isn't cool/bleeding-edge enough, it is as you say easy to create ebuilds to their liking and put in a local portage dir overlay.
And we do use p.mask ourselves as a testing area for development stuff at times, because some things need exposure in the tree before it goes stable. I agree p.mask is not really the right place for that, but it is the best place at this time.