Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]
On 09/05/2014 13:34, William Hubbs wrote: > All, > > there is a bug open requesting that we add sys-apps/iproute2 to the > system set [1]. Originally the request was to drop net-tools, but it has > become just adding iproute2. > > If no one objects, I would like to do this sometime in the next 72 > hours by adding sys-apps/iproute2 to profiles/default/linux/packages. > > Thoughts? > > William > > [1] https://bugs.gentoo.org/189149 I questioned on the original bug on net-tools vs iproute2, because netstat and ss each support different protocol families, and so compliment each other instead of replace. The same might not hold true for other components of each package. That said, the thread had deviated towards discussion on the makeup of the @system set in general, so let's rename the thread (or at least fork() it). IMHO, I think @system should maintain at least one editor and include some kind of networking diagnostic package. Even on the slower archs like MIPS, building either net-tools or iproute2 isn't asking a whole lot. Faster archs even less so. As far as editor, nano is my preference because it just works for quick edits, but an argument can be made for swapping that out with a minimal vim (which doesn't require ncurses). -- 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
Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]
On Sun, Sep 7, 2014 at 3:49 PM, Joshua Kinard wrote: > IMHO, I think @system should maintain at least one editor and include some > kind of networking diagnostic package. Why is it important that we not be able to parallel build an editor? Is it such a frequent build-time dependency that we wouldn't want to specify it? It is essential that we make it extra-hard for a user to uninstall their last editor, since it is impossible to install an editor without an editor already present? I can't imagine using a system without an editor. I can't imagine using a system without screen/tmux either. That doesn't mean that either belongs in the system set. I'd be all for keeping it in the stage3, on the install CDs, and having it in the default @world though. This is my concern with @system. Stuff gets stuck in there for the noblest of intentions, but it is the wrong solution to the problems it is being used to solve. -- Rich
Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]
On 09/07/2014 16:01, Rich Freeman wrote: > On Sun, Sep 7, 2014 at 3:49 PM, Joshua Kinard wrote: >> IMHO, I think @system should maintain at least one editor and include >> some kind of networking diagnostic package. > > Why is it important that we not be able to parallel build an editor? Is > it such a frequent build-time dependency that we wouldn't want to specify > it? It is essential that we make it extra-hard for a user to uninstall > their last editor, since it is impossible to install an editor without an > editor already present? Re: editor, I was referring to this: On 09/06/2014 09:37, Rich Freeman wrote: > There isn't much question that stuff like rsync and nano (via the > editor virtual) should be in the stage3 just so that we're not ripping > our hair out during installation. However, they really don't need to > be part of the system set. How many packages really need to depend on > an editor (and I'm talking linking and other technical issues that > affect builds - not practical use)? 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. 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. -- 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
Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]
> On Sun, 07 Sep 2014, Joshua Kinard 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. There's neither nano nor any other specific editor in the system set, to start with. There is virtual/editor which I think is the best choice, unless we would decide that no editor is needed at all. Ulrich pgpMX4Uyca61T.pgp Description: PGP signature
Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]
On 09/07/2014 16:45, Ulrich Mueller wrote: >> On Sun, 07 Sep 2014, Joshua Kinard 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. > > There's neither nano nor any other specific editor in the system set, > to start with. There is virtual/editor which I think is the best > choice, unless we would decide that no editor is needed at all. > > Ulrich The stage2/stage3 catalyst runs I did recently always dragged in nano & ncurses. I did very little customization to the build profiles or the specs, so something was favouring nano over other editors. -- 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
Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]
On Sun, Sep 7, 2014 at 4:33 PM, Joshua Kinard 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. > 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. 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. 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. -- Rich
Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]
On 09/07/2014 17:04, Rich Freeman wrote: > On Sun, Sep 7, 2014 at 4:33 PM, Joshua Kinard 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
Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]
On 09/07/2014 17:57, Joshua Kinard wrote: > > 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. Added net-tools-1.60_p20130513023548-r1.ebuild, please test. Previous: netstat -anSp: Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name sctp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 18500/sshd SCTP error in line: 2 Bug ^^ Now: Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name sctp0.0.0.0:22 LISTEN 18500/sshd sctp:::22LISTEN 18500/sshd (Yes, the re-written SCTP stats code from Fedora don't display a value when 0 or nothing is connected -- no idea why). IPX addresses are also displayed correctly: Active IPX sockets Proto Recv-Q Send-Q Local AddressForeign AddressState IPX0 0 0100:0540- IPX0 0 0100:0440- IPX0 0 0100:03403E01A8C0:0001:5104 ESTAB Now: Active IPX sockets Proto Recv-Q Send-Q Local AddressForeign AddressState IPX0 0 0001:0540- IPX0 0 0001:0440- IPX0 0 0001:0340C0A8013E:0001:5104 ESTAB If anyone encounters any problems, please let me know. Thanks!, -- 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
Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]
> On Sun, 07 Sep 2014, Joshua Kinard wrote: > On 09/07/2014 16:45, Ulrich Mueller wrote: >> There's neither nano nor any other specific editor in the system set, >> to start with. There is virtual/editor which I think is the best >> choice, unless we would decide that no editor is needed at all. > The stage2/stage3 catalyst runs I did recently always dragged in nano & > ncurses. I did very little customization to the build profiles or the > specs, so something was favouring nano over other editors. nano is preferred because it appears first in the list of dependencies in virtual/editor. Ulrich pgp1mtArXTXXd.pgp Description: PGP signature
Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]
On Sunday, September 07, 2014 05:57:57 PM Joshua Kinard wrote: > On 09/07/2014 17:04, Rich Freeman wrote: > > On Sun, Sep 7, 2014 at 4:33 PM, Joshua Kinard wrote: > >> 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. With faster hardware, I don't need as much patience. But on slower machines, as I am used to fast ones, I tend to notice the lack of parallellism during the emerge-phase. > > 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. Personally, I would not have an issue with the stage3 not having an editor, but it would make installing Gentoo more difficult considering there are some files that need to be edited. And the handbook actually references "nano". > > 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! I think both camps do the following: emerge emerge -C nano as one of the first steps. The first thing I do on a new install as soon as a portage tree is available is run the above. -- Joost
Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]
On Wed, Sep 10, 2014 at 4:08 AM, J. Roeleveld wrote: > > But on slower machines, as I am used to fast ones, I tend to notice the lack > of parallellism during the emerge-phase. > Diego used to point out that lack of parallelism was always a challenge with running a tinderbox. You can have 32 cores in your machine but it doesn't help when half the packages you want to build end up being a single-threaded task. > Personally, I would not have an issue with the stage3 not having an editor, > but it would make installing Gentoo more difficult considering there are > some files that need to be edited. And the handbook actually references > "nano". Again, I think we need to stop thinking @system = stage3 = livecd. What goes into the stage3 and what goes into @system should be two different things. Having an editor at install time is a no-brainer. -- Rich
