On Tue, 11 Apr 2017 10:09:51 +1200 Kent Fredric <ken...@gentoo.org> wrote:
> On Mon, 10 Apr 2017 16:01:55 -0400 > > You're running ~arch, I recall. Yes but most servers run stable. Though they have some ~arch packages. I may move to fully ~arch. I think stabilization on Gentoo is a misnomer. Usually newer stuff tends to be more stable than older with bugs etc. Some upstreams have release schedules that would ensure the package be outdated in Gentoo stable. My development env is all ~arch. That way I can be forewarned. Though I have allot of the same issues in stable systems. Why I do not really consider them to be such. > This means adding new is slow for arch users. Same for Java, and slower to get a JDK actually stabilized. Even worse with the from source java requirement. Since from source will most always lag binary from Oracle. > But it also means there's a clear line in the sand when something can > be stabilized. We went the route of masking and unmasking. > ~arch is not great here, but that's why arch exists: ~arch is the > buffer zone where the horrors are supposed to be exorcised. In the days I came to Gentoo. You were not allowed to break stuff in ~arch. Even though it did occur. It was very rare. If it was broken, it needed to be masked for testing till it can be safely unmasked. > But as annoying as "oh, doesn't support new target yet" is, its much > less annoying than "oh, it says it supports the new target, but > actually doesn't, and now I have portage screaming at me to toggle > use flags while I report this, and then some poor gentoo developer is > going to have to recursively find all the broken dependents and > remove their use flags" I had the issue where a month ago I swapped everything to Ruby 2.4. Then something changed, in the deps. Something wanted Ruby 2.3. as of April 3rd. My build servers last build was on the 2nd. Then I spent several hours dealing with a problem that did not exist a few week back or on April 2nd. Since more Ruby packages are getting ruby24. > Its the same hell of keywording. > > Its much easier to *add* new keywords/useflags as repoman can > trivially tell you if you made any mistakes, because repoman can only > see how your package is, and how your dependencies are. There were other things that were better on removal. paludis had some useful features. But that has changed so much last I tried to install it was a mess. Seemed to want to deviate from how portage was setup. More like one or the other not both. Both would require work. I was not very committed just playing and experimenting. Trying to get at the information I recall from using it in the past. It used to give you an idea on deps so if you were to drop something the impact. I maybe wrong, but I recall something along those lines. I imagine it still has that ability. > *removing* useflags/keywords is much messier, because repoman can't > tell you what you broke. No but I believe other tools can. > Not without doing a full tree check, which takes 30 minutes+ on my > hardware. Have you worked with paludis? If you can get that setup it should give you more useful output in less time. Ciaran would know there, and maybe some others. > Hence, that's the sort of problem I'm more inclined to throw grep at > and then run it through an automated test PR to make sure I didn't > break anything if I was really concerned. Check out paludis -- William L. Thomson Jr.
