On 09/07/2014 17:04, Rich Freeman wrote: > On Sun, Sep 7, 2014 at 4:33 PM, Joshua Kinard <ku...@gentoo.org> wrote: >> And thus, I was referring only to @system, not a stage3. I think an editor >> should be in @system, but as much as I like nano, I know the ncurses >> dependency won't sit well with everyone. If @system is supposed to be a >> minimal-working system, a minimal vim deserves consideration. But if >> ncurses is already being dragged in by something else, then stick with nano. >> > > That's the thing. I don't think that @system should be a > "minimal-working system." That has been the past attitude towards it, > and it causes issues.
Well, I was mainly just trying to fork() the thread to discuss the @system issue in general, so the smaller issue of net-tools vs iproute2 could be discussed and the bug resolved appropriately. I looked over the base/packages file and that looks fine to me right now. Couple of commented-out lines can probably be removed, but even on my slow MIPS systems, a full stage1-stage2-stage3 run only takes about 2.5 days, so I really don't have a problem with the current makeup of @system, and adding iproute2 to it isn't going to really change much. As I highlighted in the bug, only comparing netstat and ss (which is far from a comprehensive analysis), they compliment each other instead of replace. netstat supports older protocol families like IPX and AX.25 (some HAMs using Linux still use this), plus it supports showing SCTP sockets via the undocumented -S flag, as well as UDPLite. But, the SCTP support is currently broken, and Fedora's patches should fix it. ss, on the other hand, does not support SCTP, but does support DCCP (the other IANA general-purpose protocol), which netstat doesn't. Undoubtedly, there are other variances between the two packages. Before one replaces the other, we should take a look at what each package offers, find the places where they compliment each other and push whichever one has the active upstream to incorporate the missing features (likely, iproute2 needs to pickup UDPLite and SCTP support), then we can replace one with the other. As for net-tools itself, I'll see if I can get Fedora's patches to apply to it and update it. If not, I dunno whether to import their version as a separate package or as an alternate version (net-tools-2.0?). No point in ignoring it when there's obvious bugs and fixes available, even if they're not from the original upstream. >> As for Parallel builds, do you make make -jX? Or running concurrent emerges >> in different shells? I wasn't commenting at all on parallel builds. > > I was referring to --jobs. The issue with @system is that you can't > build packages in @system in parallel, or their dependencies. Now, > I'm not sure if that extends to dependencies of virtual packages - if > not then an editor isn't as much of a problem. However, you're still > stuck with lots of whining by portage if you unmerge your last editor. > I think we really need to reserve that for situations where you're > actually likely to break something. You can unmerge and re-merge an > editor without any issues at all, and there are probably lots of > useful substitutes for editors that aren't in the editor virtual. Well, I believe a stage2 in catalyst is just a remerge of @system, and that's only ~12 hours on my Octane, which is perfectly fine for me. So the parallelization isn't a real concern. Stage3 takes ~30hrs, though, so I'd be curious to see if that parallelizes well once I get SMP working on that machine. Then again, those of us who work with slower hardware probably have a much higher level of patience than others. So while the inability to parallelize the @system merge isn't a concern for me, it is for others. > I'm not suggesting that we rip out editor just now either. It makes > more sense to just try to hold the line on @system until we have > something better actually implemented (like mix-ins), and then it > won't be a big deal if we trim it down further. The editor is a total non-issue to me. I simply raised it as part of my reply to branch the thread off. I am perfectly fine keeping virtual/editor in @system and letting nano be the primary satisfier. > To cut down on replies - the reason nano is preferred is that it is > the first package in the virtual, which is the usual rule. Of course, > it was placed there deliberately since it is a simple editor with few > dependencies and both the vi and emacs camps can agree that it is > lousy. The vi and emacs camps agreeing on something? Impossible! -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
