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