Re: comps' standard group spring cleaning?
On Fri, Jan 11, 2013 at 04:46:25PM +0100, Michal Schmidt wrote: Dne 10.1.2013 21:28, Kevin Fenzi napsal(a): ok, I guess I could try again. Can we remove prelink? What does it get us these days? Has anything changed about prelink since the last time it was discussed here? prelink should not mess with running executables: http://lists.fedoraproject.org/pipermail/devel/2012-July/169819.html ? No - this is still bad, broken behaviour. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
(mashing together a few replies. Sorry about the delay.) Michael Scherer (m...@zarb.org) said: Le vendredi 11 janvier 2013 à 08:05 -0600, Chris Adams a écrit : Once upon a time, Bill Nottingham nott...@redhat.com said: - packagereqed/packagereq I don't know how widely it is used, but ed is also part of POSIX/SUS. based on my understanding, POSIX do not mandate them to be there by default, just to support them : http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html so not installing them by default will not change much, given that we already do not support several command : http://pubs.opengroup.org/onlinepubs/9699919799/utilities/toc.html ... A separate group would be better because : - this is easier to audit ( especially if the norm is updated ) - this doesn't force to install a compiler by default ( fort77 ) Things like ed bc are required by redhat-lsb-core. (You can repoquery it for its full list). Would it be worth it to just list that, and not worry about the smaller things? Biggest size downfall to this is that it drags cups into the system. :/ Chris Adams (cmad...@hiwaay.net) said: - packagereqftp/packagereq Either ftp or lftp should still be in the standard install (command line FTP is sometimes essential, especially when trying to add to a minimal install). lftp is bigger than ftp (because lftp does more, such as sftp and http). If you're adding to an install, and you already have curl, rsync, and sftp, how much do you need an interactive ftp client itself? - packagereqbtrfs-progs/packagereq Will be installed by anaconda if you install on btrfs; can move to @core if it becomes the default FS. There are several common things that you list as installed by anaconda if needed; that can give you problems if you install in one system or setup and then move the drive, add other drives, etc. Sure, but I would assume that if you're doing that, you know what you're doing. - packagereqlftp/packagereq Removed; ftp is in legacy-unix. If legacy-unix is not part of standard install, that is a poor justification (we removed one FTP client, so better remove the other as well). The idea is that if the functionality is provided elsewhere, all uses of it should go there; splitting the functionality between groups doesn't make much sense. I guess my comments get back to: is there a defined goal, other than remove things Bill doesn't use (not trying to pick on you Bill, but you did make this list)? Are we trying to shrink the installed disk footprint (none of the these are very big)? Does removing these reduce install time significantly? This came up in the bugzilla ticket as well, and it's probably a better place to start. So, first principles of the group, IMO: 'Standard' would be 'tools and utilities you expect to be on a standard Linux install, but that aren't needed in a minimal install'. It's included in every non-minimal install. (In general, that means all the desktops; people who install servers usually start at minimal and work their way up.) This then brings up the following discussion points: * bc, ed, talk, etc. Should we just list redhat-lsb-core? * ftp vs lftp, info vs pinfo, traceroute vs mtr If we're talking about a 'standard' group of things that people would expect to be there, then perhaps we drop all the newer, better version of things. Sure, people still can install and use pinfo or mtr. But is that the standard that people expect to be there every time? * ftp, finger, etc. Are these things that are still expected in a 'standard' Linux install? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On 01/11/2013 05:52 PM, Chris Adams wrote: If you want to replace netstat and ifconfig, that's fine, but make a new netstat and ifconfig (or at least wrappers that handle the common options and give similar output). Why do people want to reinvent the wheel (and ignore all previous wheels)? If you want to replace bonding ... If you want to replace sysvinit ... If you want to replace libc5 ... If you want to replace ipfwadm ... If you want to replace a.out ... If you want to replace 386BSD ... If you want to replace put your favorite feature here Welcome to LiNUX. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On 01/11/2013 02:51 PM, Chris Adams wrote: Once upon a time, Xose Vazquez Perez xose.vazquez at gmail.com said: On 01/11/2013 01:17 AM, Kevin Kofler wrote: +1, the default info is really a PITA to use, pinfo is much better. -1, pinfo is dispensable: $ info ls --subnodes --output - | less Ah yes, because _that's_ intuitive (especially when you are trying to find information to fix an immediate problem). A similar command is included in the _man page_ of info, EXAMPLES section. Anyway, *minimal* doesn't need superfluous programs. Even docs should not be installed, --excludedocs(rpm), under minimal. Why not eliminate less and more then? You can always replace them with a shell loop. Does people understand what _minimal_ means ? pinfo and others stills are in the distribution, you can install it later. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Sun, Jan 13, 2013 at 02:31:09AM +0100, Xose Vazquez Perez wrote: Ah yes, because _that's_ intuitive (especially when you are trying to find information to fix an immediate problem). A similar command is included in the _man page_ of info, EXAMPLES section. Anyway, *minimal* doesn't need superfluous programs. But, again, we're not talking about minimal here. This is the set of packages up a level from that -- installed by default on non-minimal installs. Does people understand what _minimal_ means ? pinfo and others stills are in the distribution, you can install it later. If you want that, yes, do a minimal install. For a standard install, I think it's good to install basic, small utilities that make the system more pleasant to use. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Once upon a time, Xose Vazquez Perez xose.vazq...@gmail.com said: Does people understand what _minimal_ means ? Please see the subject; this thread is not about the minimal install (any changes there should probably be in a different thread). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Le Jeu 10 janvier 2013 23:33, Bill Nottingham a écrit : - packagereqtelnet/packagereq Nowadays it's commonly used to test if a port is open, not to log in remotely somewhere. What will replace it in this role? -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On 01/11/2013 12:01 AM, William Brown wrote: Nothing I didn't know about it. Will read into it now. Maybe this shows that a documentation component is needed, to bridge the gap to say X tool is replaced by Y IE netstat - ss man netstat: NOTE This program is obsolete. Replacement for netstat is ss. Replacement for netstat -r is ip route. Replacement for netstat -i is ip -s link. Replacement for netstat -g is ip maddr. net-tools is obsolete [1] since *fourteen* year ago. And also some tools from iputils: arping ping ifenslave tftpd traceroute6 [1] http://lists.debian.org/debian-devel/2009/03/msg00780.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Fri, Jan 11, 2013 at 11:24:00AM +0100, Nicolas Mailhot wrote: Le Jeu 10 janvier 2013 23:33, Bill Nottingham a écrit : - packagereqtelnet/packagereq Nowadays it's commonly used to test if a port is open, not to log in remotely somewhere. What will replace it in this role? nc (from nmap-ncat). -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On 01/11/2013 01:17 AM, Kevin Kofler wrote: +1, the default info is really a PITA to use, pinfo is much better. -1, pinfo is dispensable: $ info ls --subnodes --output - | less -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On 01/11/2013 11:35 AM, Xose Vazquez Perez wrote: On 01/11/2013 12:01 AM, William Brown wrote: Nothing I didn't know about it. Will read into it now. Maybe this shows that a documentation component is needed, to bridge the gap to say X tool is replaced by Y IE netstat - ss man netstat: NOTE This program is obsolete. Replacement for netstat is ss. Replacement for netstat -r is ip route. Replacement for netstat -i is ip -s link. Replacement for netstat -g is ip maddr. netstat is still widely used ... ... sounds like the plan to obsolete them has failed. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Le vendredi 11 janvier 2013 à 11:24 +0100, Nicolas Mailhot a écrit : Le Jeu 10 janvier 2013 23:33, Bill Nottingham a écrit : - packagereqtelnet/packagereq Nowadays it's commonly used to test if a port is open, not to log in remotely somewhere. What will replace it in this role? why not bash :) $ cat /dev/tcp/localhost/22 SSH-2.0-OpenSSH_6.1 -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Fri, Jan 11, 2013 at 01:35:46PM +0100, Michael Scherer wrote: Le vendredi 11 janvier 2013 à 11:24 +0100, Nicolas Mailhot a écrit : Le Jeu 10 janvier 2013 23:33, Bill Nottingham a écrit : - packagereqtelnet/packagereq Nowadays it's commonly used to test if a port is open, not to log in remotely somewhere. What will replace it in this role? why not bash :) $ cat /dev/tcp/localhost/22 SSH-2.0-OpenSSH_6.1 But for remote $ telnet damn-web_server 80 GET / HTTP/1.0 in any case, we can keep it, but moving it out of the standard group definitely makes sense ! Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Once upon a time, Xose Vazquez Perez xose.vazq...@gmail.com said: On 01/11/2013 01:17 AM, Kevin Kofler wrote: +1, the default info is really a PITA to use, pinfo is much better. -1, pinfo is dispensable: $ info ls --subnodes --output - | less Ah yes, because _that's_ intuitive (especially when you are trying to find information to fix an immediate problem). Why not eliminate less and more then? You can always replace them with a shell loop. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Once upon a time, Bill Nottingham nott...@redhat.com said: Sure, going through the diff: - packagereqbc/packagereq bc and dc are sometimes used for math in shell scripts (and bc is part of POSIX/SUS). - packagereqed/packagereq I don't know how widely it is used, but ed is also part of POSIX/SUS. - packagereqftp/packagereq Either ftp or lftp should still be in the standard install (command line FTP is sometimes essential, especially when trying to add to a minimal install). lftp is bigger than ftp (because lftp does more, such as sftp and http). - packagereqtalk/packagereq Another thing not widely used but part of POSIX/SUS. - packagereqtelnet/packagereq Commonly used for debugging a wide variety of issues. - packagereqbtrfs-progs/packagereq Will be installed by anaconda if you install on btrfs; can move to @core if it becomes the default FS. There are several common things that you list as installed by anaconda if needed; that can give you problems if you install in one system or setup and then move the drive, add other drives, etc. - packagereqdmraid/packagereq Will be installed by anaconda if you need it. See above - may be required if you (for example) disconnect all but the OS drive during install and then put the others back. - packagereqlftp/packagereq Removed; ftp is in legacy-unix. If legacy-unix is not part of standard install, that is a poor justification (we removed one FTP client, so better remove the other as well). - packagereqmdadm/packagereq Will be installed by anaconda if you need it (and pulled in by udisks2 if you install that.) See above - may be required if you (for example) disconnect all but the OS drive during install and then put the others back. - packagereqwireless-tools/packagereq Functionality subsumed by iw. Although this is perhaps premature until initscripts gets ported to it. I would think so. You could remove wireless-tools from comps and add it as a Requires to initscripts, but then somebody not using wireless couldn't remove it. I guess my comments get back to: is there a defined goal, other than remove things Bill doesn't use (not trying to pick on you Bill, but you did make this list)? Are we trying to shrink the installed disk footprint (none of the these are very big)? Does removing these reduce install time significantly? I understand removing support for hardware items that very few have any more (that's what started this discussion). I'm just not sure about a wholesale removal of a bunch of still-useful stuff. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Le vendredi 11 janvier 2013 à 21:14 +0800, Daniel Veillard a écrit : On Fri, Jan 11, 2013 at 01:35:46PM +0100, Michael Scherer wrote: Le vendredi 11 janvier 2013 à 11:24 +0100, Nicolas Mailhot a écrit : Le Jeu 10 janvier 2013 23:33, Bill Nottingham a écrit : - packagereqtelnet/packagereq Nowadays it's commonly used to test if a port is open, not to log in remotely somewhere. What will replace it in this role? why not bash :) $ cat /dev/tcp/localhost/22 SSH-2.0-OpenSSH_6.1 But for remote $ telnet damn-web_server 80 GET / HTTP/1.0 http://thesmithfam.org/blog/2006/05/23/bash-socket-programming-with-devtcp-2/ in any case, we can keep it, but moving it out of the standard group definitely makes sense ! +1 telnet is easier, but that's a task that do not happen so often, and people who are able to perform it are also fully able to find the tool for that ( and nc is better than telnet on this point, as this permit more ) -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Thu, Jan 10, 2013 at 03:08:21PM -0500, Bill Nottingham wrote: +idlegacy-unix/id +_nameLegacy Unix Support/_name +_descriptionThese packages include clients and commands for legacy unix environments./_description +defaultfalse/default I'm not a big fan of this. It mashes a lot of disparate cases together. +uservisiblefalse/uservisible +packagelist + packagereqbc/packagereq Very likely to be used in scripts. There's a reasonable expectation for this to be there. I think it should stay in @standard. + packagereqed/packagereq Much less likely these days. But whatever. + packagereqfinger/packagereq The network protocol is obsolete, but as evidenced by the discussion people still do use it. + packagereqftp/packagereq This is one of those things where if I'm going to install something _on purpose_, I'd just use lftp, but which, were I providing an environment for other people, I'd put there as a courtesy. Maybe that's what Legacy Unix Support means. + packagereqrsh/packagereq On the other hand, this one I wouldn't include, because it's an easy upsell to ssh. + packagereqtalk/packagereq This is a historical curiosity and unlikely to be useful to people who want the other things. + packagereqtelnet/packagereq Incredibly common for testing network connectivity. I think this should stay in standard. + packagereqypbind/packagereq But *this* is environment-specific, and these days most people won't need it at all. I don't think it belongs in any group. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Thu, Jan 10, 2013 at 01:28:23PM -0700, Kevin Fenzi wrote: prelink. Ugh. ok, I guess I could try again. Can we remove prelink? What does it get us these days? I'm happy to back a feature to drop it. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Thu, Jan 10, 2013 at 03:21:18PM -0700, Stephen John Smoogen wrote: Remember this is removal from core NOT from the distribution.. Actually, it's about @standard, not @core. Keeping the core minimal makes sense but I think @standard should provide a comfortable working environment. People may disagree about what's in here, but the threshold should be much easier. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Thu, Jan 10, 2013 at 05:33:28PM -0500, Bill Nottingham wrote: - packagereqtime/packagereq bash has this builtin; don't think the additional features warrant this on every non-minimal install. However, it has different semantics from the bash builtin, and it's likely that people have scripts which use it. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Fri, Jan 11, 2013 at 03:09:28PM +0100, Michael Scherer wrote: telnet is easier, but that's a task that do not happen so often, and people who are able to perform it are also fully able to find the tool I think both the but and the and are not necessarily true. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On 01/11/2013 02:14 PM, Daniel Veillard wrote: On Fri, Jan 11, 2013 at 01:35:46PM +0100, Michael Scherer wrote: Le vendredi 11 janvier 2013 à 11:24 +0100, Nicolas Mailhot a écrit : Le Jeu 10 janvier 2013 23:33, Bill Nottingham a écrit : - packagereqtelnet/packagereq Nowadays it's commonly used to test if a port is open, not to log in remotely somewhere. What will replace it in this role? why not bash :) $ cat /dev/tcp/localhost/22 SSH-2.0-OpenSSH_6.1 But for remote $ telnet damn-web_server 80 GET / HTTP/1.0 Furthermore, telnet performs LF - CRLF translation, and some alternatives don't, at least by default. This conversion is required for protocol-compliant HTTP, and some web servers insist on CRLF line endings. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Le vendredi 11 janvier 2013 à 08:05 -0600, Chris Adams a écrit : Once upon a time, Bill Nottingham nott...@redhat.com said: - packagereqed/packagereq I don't know how widely it is used, but ed is also part of POSIX/SUS. based on my understanding, POSIX do not mandate them to be there by default, just to support them : http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html so not installing them by default will not change much, given that we already do not support several command : http://pubs.opengroup.org/onlinepubs/9699919799/utilities/toc.html I see asa, cflow, cxref, delta, fort77, yacc who would make use fail at POSIX conformance, since none of them are installed by default ( and I just quickly looked at the list ). And while I agree the goal to be POSIX compliant is nice, as far as i know, we are not, so we do not claim to be. ( ie, people cannot and should not expect the system to have theses utilities by default ). So maybe a separate group ( and feature, since that's a rather lengthy task ) for them would be a start, and then packaging and adding the missing utilities would be the next step before claiming we are compliant. A separate group would be better because : - this is easier to audit ( especially if the norm is updated ) - this doesn't force to install a compiler by default ( fort77 ) -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Fri, Jan 11, 2013 at 03:47:40PM +0100, Michael Scherer wrote: And while I agree the goal to be POSIX compliant is nice, as far as i know, we are not, so we do not claim to be. ( ie, people cannot and should not expect the system to have theses utilities by default ). Yeah, but it's reasonable for people to expect that scripts using standard commands which have always worked on Fedora to continue to work on Fedora unless there's a good reason for them to not. That doesn't mean we need to carry cruft for ever, but we should error on the side of compatibly in the absence of a reason. (And I think saving 120k in non-minimal installs doesn't count.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Dne 10.1.2013 21:28, Kevin Fenzi napsal(a): ok, I guess I could try again. Can we remove prelink? What does it get us these days? Has anything changed about prelink since the last time it was discussed here? prelink should not mess with running executables: http://lists.fedoraproject.org/pipermail/devel/2012-July/169819.html ? Or even since prelink: is it worth it?: http://lists.fedoraproject.org/pipermail/devel/2009-July/034529.html Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Fri, Jan 11, 2013 at 04:46:25PM +0100, Michal Schmidt wrote: ok, I guess I could try again. Can we remove prelink? What does it get us these days? Has anything changed about prelink since the last time it was discussed here? prelink should not mess with running executables: http://lists.fedoraproject.org/pipermail/devel/2012-July/169819.html ? Or even since prelink: is it worth it?: http://lists.fedoraproject.org/pipermail/devel/2009-July/034529.html Hardware is faster and any benefit less necessary, making it even less worth the tradeoffs? I'd like to see some numbers. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Once upon a time, Matthew Miller mat...@fedoraproject.org said: On Fri, Jan 11, 2013 at 04:46:25PM +0100, Michal Schmidt wrote: ok, I guess I could try again. Can we remove prelink? What does it get us these days? Has anything changed about prelink since the last time it was discussed here? prelink should not mess with running executables: http://lists.fedoraproject.org/pipermail/devel/2012-July/169819.html ? Or even since prelink: is it worth it?: http://lists.fedoraproject.org/pipermail/devel/2009-July/034529.html Hardware is faster and any benefit less necessary, making it even less worth the tradeoffs? I'd like to see some numbers. Before you go too far with this, can prelink be discussed in its own thread? I forsee that swamping the rest of this discussion. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Fri, 11 Jan 2013 10:55:21 -0500 Matthew Miller mat...@fedoraproject.org wrote: On Fri, Jan 11, 2013 at 04:46:25PM +0100, Michal Schmidt wrote: ok, I guess I could try again. Can we remove prelink? What does it get us these days? Has anything changed about prelink since the last time it was discussed here? prelink should not mess with running executables: http://lists.fedoraproject.org/pipermail/devel/2012-July/169819.html ? Or even since prelink: is it worth it?: http://lists.fedoraproject.org/pipermail/devel/2009-July/034529.html Hardware is faster and any benefit less necessary, making it even less worth the tradeoffs? I'd like to see some numbers. Additionally, a number of things in fedora are now being built with PIE and thus cannot be prelinked. (ok, a number is probibly an exaggeration, but it's a few at least). kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Am 11.01.2013 11:35, schrieb Xose Vazquez Perez: On 01/11/2013 12:01 AM, William Brown wrote: Nothing I didn't know about it. Will read into it now. Maybe this shows that a documentation component is needed, to bridge the gap to say X tool is replaced by Y IE netstat - ss man netstat: NOTE This program is obsolete. Replacement for netstat is ss. Replacement for netstat -r is ip route. Replacement for netstat -i is ip -s link. Replacement for netstat -g is ip maddr. net-tools is obsolete [1] since *fourteen* year ago. And also some tools from iputils: arping ping ifenslave tftpd traceroute6 sarcasmoh yeah ss is a pretty clear and self explaining command/sarcasm if people would develop SMART repalcements they would call the binaries identical with compatible command line switches so a Obsoletes: whatever would not change the USER INTERFACES fine, you can add addtionoal command line options, you can even add new specialized binaries in the same package but say command A with other options replaces well known B is pretty dumb at all signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Fri, 11 Jan 2013 11:40:40 +0100 Reindl Harald h.rei...@thelounge.net wrote: sarcasmoh yeah ss is a pretty clear and self explaining command/sarcasm if people would develop SMART repalcements they would call the binaries identical with compatible command line switches so a Obsoletes: whatever would not change the USER INTERFACES ss is not command line compatible with netstart AFAIK. It provides similar information... fine, you can add addtionoal command line options, you can even add new specialized binaries in the same package but say command A with other options replaces well known B is pretty dumb at all It takes a long time as we see for new replacements to gain traction, but things change. :) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Lennart, Just my $0.02 on halting the inclusion of these: we might want to make these available in case there is a user out there who can only afford the older hardware. On Jan 10, 2013 7:00 AM, Lennart Poettering mzerq...@0pointer.de wrote: Heya, I noticed that comps' standard group includes a lot of packages that were all the hotness in 1990s but aren't really that much anymore. For example, irda-tools, pcmciautils, finger, rsh, rdist, pinfo have probably had their best times behind them, and probably shouldn't be installed by default anymore. I'd like to propose that maybe it is time to remove these from standard for F19. Note sure how to proceed on that. Propose a feature? File a bug? Is there even a comps maintainer? (Oh, and to clarify this: it's just about what to install by default, not about what to ship. It's just that I have a hard time remembering when i saw the last laptop with irda or pcmcia ports, and maybe we should not install that anymore by default...) Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Once upon a time, Kevin Fenzi ke...@scrye.com said: ss is not command line compatible with netstart AFAIK. It provides similar information... And IMHO that is the problem. Why did someone see it as a good idea to develop a replacement for well-known commands (that have existed in various forms on a lot of other OSes) and not make them at least somewhat compatible with what they were replacing? If you want to replace netstat and ifconfig, that's fine, but make a new netstat and ifconfig (or at least wrappers that handle the common options and give similar output). Why do people want to reinvent the wheel (and ignore all previous wheels)? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Le vendredi 11 janvier 2013 à 08:39 -0800, Richard Vickery a écrit : Lennart, Just my $0.02 on halting the inclusion of these: we might want to make these available in case there is a user out there who can only afford the older hardware. They are available, the point is to not install them by default, not to remove them totally. IE, if someone has the old hardware, he can still install them. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Chris Adams wrote: Why do people want to reinvent the wheel (and ignore all previous wheels)? Because choice. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Hi Lennart, I would like to remove finger from the list. It is still very much in use. I use it many times daily. I realize my use case is multiuser and server systems - not of interest to Fedora - but the overhead is little, so I would be grateful if it remained. Jon. -- Sent from my iPad On Jan 10, 2013, at 10:07, Lennart Poettering mzerq...@0pointer.de wrote: Heya, I noticed that comps' standard group includes a lot of packages that were all the hotness in 1990s but aren't really that much anymore. For example, irda-tools, pcmciautils, finger, rsh, rdist, pinfo have probably had their best times behind them, and probably shouldn't be installed by default anymore. I'd like to propose that maybe it is time to remove these from standard for F19. Note sure how to proceed on that. Propose a feature? File a bug? Is there even a comps maintainer? (Oh, and to clarify this: it's just about what to install by default, not about what to ship. It's just that I have a hard time remembering when i saw the last laptop with irda or pcmcia ports, and maybe we should not install that anymore by default...) Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Thu, 2013-01-10 at 14:11 -0600, Chris Adams wrote: Once upon a time, john.flor...@dart.biz john.flor...@dart.biz said: I use finger effectively without a finger server, on a single-user workstation (in multi-user mode, of course). I believe it's getting the data via NSS and in my case that means LDAP. That's not too esoteric IMHO. Yeah, finger is kind of a multi-purpose tool. It can show logged-in users as well as fetch info about any user. Sadly, it appears you can't finger John Carmack any more. He's gone all shy. (I think that still worked up to at least 2005 or so). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
comps' standard group spring cleaning?
Heya, I noticed that comps' standard group includes a lot of packages that were all the hotness in 1990s but aren't really that much anymore. For example, irda-tools, pcmciautils, finger, rsh, rdist, pinfo have probably had their best times behind them, and probably shouldn't be installed by default anymore. I'd like to propose that maybe it is time to remove these from standard for F19. Note sure how to proceed on that. Propose a feature? File a bug? Is there even a comps maintainer? (Oh, and to clarify this: it's just about what to install by default, not about what to ship. It's just that I have a hard time remembering when i saw the last laptop with irda or pcmcia ports, and maybe we should not install that anymore by default...) Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
From: Lennart Poettering mzerq...@0pointer.de Heya, I noticed that comps' standard group includes a lot of packages that were all the hotness in 1990s but aren't really that much anymore. For example, irda-tools, pcmciautils, finger, rsh, rdist, pinfo have probably had their best times behind them, and probably shouldn't be installed by default anymore. I'd like to propose that maybe it is time to remove these from standard for F19. Note sure how to proceed on that. Propose a feature? File a bug? Is there even a comps maintainer? (Oh, and to clarify this: it's just about what to install by default, not about what to ship. It's just that I have a hard time remembering when i saw the last laptop with irda or pcmcia ports, and maybe we should not install that anymore by default...) Lennart -- Lennart Poettering - Red Hat, Inc. I agree with all those suggested, except for perhaps finger. Unfortunately, I don't think companies ID'ing their employees by number has gone out of style. I for one will continue to always install finger because I can't remember who 'd54321' is and finger really helps with that. (Although, I'm also probably the only gray beard in the company that uses this. :-) -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Thu, Jan 10, 2013 at 9:12 AM, john.flor...@dart.biz wrote: From: Lennart Poettering mzerq...@0pointer.de Heya, I noticed that comps' standard group includes a lot of packages that were all the hotness in 1990s but aren't really that much anymore. For example, irda-tools, pcmciautils, finger, rsh, rdist, pinfo have probably had their best times behind them, and probably shouldn't be installed by default anymore. I'd like to propose that maybe it is time to remove these from standard for F19. Note sure how to proceed on that. Propose a feature? File a bug? Is there even a comps maintainer? (Oh, and to clarify this: it's just about what to install by default, not about what to ship. It's just that I have a hard time remembering when i saw the last laptop with irda or pcmcia ports, and maybe we should not install that anymore by default...) Lennart -- Lennart Poettering - Red Hat, Inc. I agree with all those suggested, except for perhaps finger. Unfortunately, I don't think companies ID'ing their employees by number has gone out of style. I for one will continue to always install finger because I can't remember who 'd54321' is and finger really helps with that. (Although, I'm also probably the only gray beard in the company that uses this. :-) maybe i'm weird too, but ya.. i use finger more than who -greg -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Once upon a time, Lennart Poettering mzerq...@0pointer.de said: I noticed that comps' standard group includes a lot of packages that were all the hotness in 1990s but aren't really that much anymore. For example, irda-tools, pcmciautils, finger, rsh, rdist, pinfo have probably had their best times behind them, and probably shouldn't be installed by default anymore. pinfo is the (IMHO) best console info page reader, and until we stop having man pages that say see the info page for real documentation and/or packages that only ship info pages, pinfo should stay (and should be at the same default install level as man). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Thu, 10.01.13 09:55, Chris Adams (cmad...@hiwaay.net) wrote: Once upon a time, Lennart Poettering mzerq...@0pointer.de said: I noticed that comps' standard group includes a lot of packages that were all the hotness in 1990s but aren't really that much anymore. For example, irda-tools, pcmciautils, finger, rsh, rdist, pinfo have probably had their best times behind them, and probably shouldn't be installed by default anymore. pinfo is the (IMHO) best console info page reader, and until we stop having man pages that say see the info page for real documentation and/or packages that only ship info pages, pinfo should stay (and should be at the same default install level as man). My mail wasn't really about the specifics what to remove but how to get themn removed. But I'll bite anyway: we hardly need two info readers installed by default, do we? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Lennart Poettering (mzerq...@0pointer.de) said: On Thu, 10.01.13 09:55, Chris Adams (cmad...@hiwaay.net) wrote: Once upon a time, Lennart Poettering mzerq...@0pointer.de said: I noticed that comps' standard group includes a lot of packages that were all the hotness in 1990s but aren't really that much anymore. For example, irda-tools, pcmciautils, finger, rsh, rdist, pinfo have probably had their best times behind them, and probably shouldn't be installed by default anymore. pinfo is the (IMHO) best console info page reader, and until we stop having man pages that say see the info page for real documentation and/or packages that only ship info pages, pinfo should stay (and should be at the same default install level as man). My mail wasn't really about the specifics what to remove but how to get themn removed. But I'll bite anyway: we hardly need two info readers installed by default, do we? Then remove the other one? With respect to the others... most could go. I honestly thought pcmciautils was gone already, but perhaps that was for something else. Most of the storage stuff can go too in favor of being brought in either at installation, or by deps of other tools. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Thu, 10.01.13 11:13, Bill Nottingham (nott...@redhat.com) wrote: Lennart Poettering (mzerq...@0pointer.de) said: On Thu, 10.01.13 09:55, Chris Adams (cmad...@hiwaay.net) wrote: Once upon a time, Lennart Poettering mzerq...@0pointer.de said: I noticed that comps' standard group includes a lot of packages that were all the hotness in 1990s but aren't really that much anymore. For example, irda-tools, pcmciautils, finger, rsh, rdist, pinfo have probably had their best times behind them, and probably shouldn't be installed by default anymore. pinfo is the (IMHO) best console info page reader, and until we stop having man pages that say see the info page for real documentation and/or packages that only ship info pages, pinfo should stay (and should be at the same default install level as man). My mail wasn't really about the specifics what to remove but how to get themn removed. But I'll bite anyway: we hardly need two info readers installed by default, do we? Then remove the other one? With respect to the others... most could go. I honestly thought pcmciautils was gone already, but perhaps that was for something else. Most of the storage stuff can go too in favor of being brought in either at installation, or by deps of other tools. How shall I proceed with this? file a feature for fesco? file a bug? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Lennart Poettering (mzerq...@0pointer.de) said: Then remove the other one? With respect to the others... most could go. I honestly thought pcmciautils was gone already, but perhaps that was for something else. Most of the storage stuff can go too in favor of being brought in either at installation, or by deps of other tools. How shall I proceed with this? file a feature for fesco? file a bug? A bug should be fine, although I was going to start poking at a patch later today now that it's been brought up. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Thu, Jan 10, 2013 at 09:29:43AM -0600, Greg Swift wrote: maybe i'm weird too, but ya.. i use finger more than who I think alias in your bashrc is the answer here. :) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Thu, 10.01.13 11:33, Bill Nottingham (nott...@redhat.com) wrote: Lennart Poettering (mzerq...@0pointer.de) said: Then remove the other one? With respect to the others... most could go. I honestly thought pcmciautils was gone already, but perhaps that was for something else. Most of the storage stuff can go too in favor of being brought in either at installation, or by deps of other tools. How shall I proceed with this? file a feature for fesco? file a bug? A bug should be fine, although I was going to start poking at a patch later today now that it's been brought up. Ah, there's a bz component for that, I wasn't aware. Filed this now: https://bugzilla.redhat.com/show_bug.cgi?id=894110 Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Once upon a time, Lennart Poettering mzerq...@0pointer.de said: But I'll bite anyway: we hardly need two info readers installed by default, do we? Well, I'd agree with that. The problem (again IMHO) with info is that it works for emacs users (or at least that's what I guess, I never can figure it out), while pinfo operates more like a console web browser (such as lynx). However, you can't remove info, because it provides /sbin/install-info (which is required by every package that provides info files). I still think pinfo should stay. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Once upon a time, Matthew Miller mat...@fedoraproject.org said: On Thu, Jan 10, 2013 at 09:29:43AM -0600, Greg Swift wrote: maybe i'm weird too, but ya.. i use finger more than who I think alias in your bashrc is the answer here. :) finger and who don't do the same thing, so an alias isn't going to help. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Thu, Jan 10, 2013 at 01:28:01PM -0600, Chris Adams wrote: On Thu, Jan 10, 2013 at 09:29:43AM -0600, Greg Swift wrote: maybe i'm weird too, but ya.. i use finger more than who I think alias in your bashrc is the answer here. :) finger and who don't do the same thing, so an alias isn't going to help. Well, it may help enough. Or alias it to getent if that's what you're looking for. Or, if nothing is close enough: alias finger=echo Don\'t do that. But finger can still be installed on the multiple-user systems that still persist, or in any environments which still run finger servers. (Are there any?) I think the case is pretty good that it's obsolete. Fun fact™: I learned from this conversation that my default personal user environment still contains a .plan file. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Thu, 10 Jan 2013, Matthew Miller wrote: On Thu, Jan 10, 2013 at 01:28:01PM -0600, Chris Adams wrote: On Thu, Jan 10, 2013 at 09:29:43AM -0600, Greg Swift wrote: maybe i'm weird too, but ya.. i use finger more than who I think alias in your bashrc is the answer here. :) finger and who don't do the same thing, so an alias isn't going to help. Well, it may help enough. Or alias it to getent if that's what you're looking for. Or, if nothing is close enough: alias finger=echo Don\'t do that. But finger can still be installed on the multiple-user systems that still persist, or in any environments which still run finger servers. (Are there any?) I think the case is pretty good that it's obsolete. Fun fact™: I learned from this conversation that my default personal user environment still contains a .plan file. What was in your plan? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Thu, Jan 10, 2013 at 02:46:08PM -0500, Seth Vidal wrote: Fun fact™: I learned from this conversation that my default personal user environment still contains a .plan file. What was in your plan? I can't tell you. It's a Secret Plan. (That's what it says. I'm pretty sure it dates back to 1993 when I got my first VAX account.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Thu, 10 Jan 2013, Matthew Miller wrote: On Thu, Jan 10, 2013 at 02:46:08PM -0500, Seth Vidal wrote: Fun fact™: I learned from this conversation that my default personal user environment still contains a .plan file. What was in your plan? I can't tell you. It's a Secret Plan. (That's what it says. I'm pretty sure it dates back to 1993 when I got my first VAX account.) I used to have a .agenda file so I could tell people I had a hidden agenda. :) -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
From: Matthew Miller mat...@fedoraproject.org But finger can still be installed on the multiple-user systems that still persist, or in any environments which still run finger servers. (Are there any?) I think the case is pretty good that it's obsolete. I use finger effectively without a finger server, on a single-user workstation (in multi-user mode, of course). I believe it's getting the data via NSS and in my case that means LDAP. That's not too esoteric IMHO. Again though, I'm not troubled by having to install it either; I'll just add it to my puppet manifests if necessary. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Seth Vidal (skvi...@fedoraproject.org) said: Fun fact™: I learned from this conversation that my default personal user environment still contains a .plan file. What was in your plan? Why, the same thing we do every night, Pinky... In any case, attached is the initial diff I have. Some additional ideas, and reasons why I may have left things Iin that were suggested to remove... bind-utils in core? mailcap can probably be dropped and only brought in via requirements, unless people know of lots of users of it that don't require it. bridge-utils is needed to configure bridges, and is small. You can create a bridge with /sbin/ip, but not add interfaces to it. iptstate is left in for now. Perhaps this should move to firewalld? Much like pinfo/info, there is mtr and traceroute. As a philosophy, should we by default be including 'better' versions of ancient unix tools instead of the standard ones? We should probably split off network auth, network filesystem tools, and smart card auth, into their own separate groups. btrfs-progs is dropped from @standard, but will get added to @core if/when it becomes the default FS. (Anaconda will still add it if you use it.) numactl... I'd wait until autonuma lands upstream, but we could potentially remove it. prelink. Ugh. smartmontools... could be dropped, if people don't use it much. All it does out of the box is e-mail root (and throw messages at the tty.) setuptool should probably be cleaned up or removed. Bill diff --git a/comps-f19.xml.in b/comps-f19.xml.in index 4be1207..1953f85 100644 --- a/comps-f19.xml.in +++ b/comps-f19.xml.in @@ -1195,52 +1195,35 @@ packagereqat/packagereq packagereqattr/packagereq packagereqauthconfig/packagereq - packagereqbc/packagereq packagereqbind-utils/packagereq packagereqbzip2/packagereq packagereqcpio/packagereq packagereqcrontabs/packagereq - packagereqcyrus-sasl-plain/packagereq - packagereqdbus/packagereq - packagereqed/packagereq packagereqfile/packagereq packagereqfirewalld/packagereq - packagereqlogrotate/packagereq packagereqlsof/packagereq packagereqmailcap/packagereq - packagereqntsysv/packagereq packagereqpciutils/packagereq packagereqpsacct/packagereq packagereqquota/packagereq - packagereqtmpwatch/packagereq packagereqtraceroute/packagereq packagereq type=conditional requires=system-config-datechrony/packagereq packagereqbash-completion/packagereq packagereqbridge-utils/packagereq - packagereqbtrfs-progs/packagereq packagereqcifs-utils/packagereq - packagereqcoolkey/packagereq packagereqcryptsetup/packagereq - packagereqdmraid/packagereq packagereqdos2unix/packagereq packagereqdosfstools/packagereq - packagereqdump/packagereq packagereqethtool/packagereq packagereqfedora-release-notes/packagereq - packagereqfinger/packagereq - packagereqfprintd-pam/packagereq - packagereqftp/packagereq packagereqgnupg2/packagereq packagereqhunspell/packagereq packagereqiptstate/packagereq - packagereqirda-utils/packagereq packagereqirqbalance/packagereq packagereqjwhois/packagereq packagereqkrb5-workstation/packagereq - packagereqlftp/packagereq packagereqman-pages/packagereq packagereqmcelog/packagereq - packagereqmdadm/packagereq packagereqmicrocode_ctl/packagereq packagereqmlocate/packagereq packagereqmtr/packagereq @@ -1253,42 +1236,26 @@ packagereqnumactl/packagereq packagereqPackageKit-yum-plugin/packagereq packagereqpam_krb5/packagereq - packagereqpam_pkcs11/packagereq - packagereqpasswdqc/packagereq - packagereqpcmciautils/packagereq packagereqpinfo/packagereq packagereqplymouth/packagereq - packagereqpm-utils/packagereq packagereqprelink/packagereq - packagereqrdate/packagereq - packagereqrdist/packagereq packagereqrealmd/packagereq packagereqrng-tools/packagereq - packagereqrsh/packagereq packagereqrsync/packagereq packagereqsendmail/packagereq packagereqsetuptool/packagereq packagereqsmartmontools/packagereq packagereqsos/packagereq packagereqsssd/packagereq - packagereqstunnel/packagereq packagereqsudo/packagereq packagereqsymlinks/packagereq - packagereqtalk/packagereq packagereqtar/packagereq packagereqtcpdump/packagereq packagereqtcp_wrappers/packagereq - packagereqtelnet/packagereq - packagereqtime/packagereq - packagereqtree/packagereq packagerequnzip/packagereq packagerequsbutils/packagereq - packagereqvconfig/packagereq - packagereqwget/packagereq packagereqwhich/packagereq - packagereqwireless-tools/packagereq packagereqwords/packagereq -
Re: comps' standard group spring cleaning?
Once upon a time, john.flor...@dart.biz john.flor...@dart.biz said: I use finger effectively without a finger server, on a single-user workstation (in multi-user mode, of course). I believe it's getting the data via NSS and in my case that means LDAP. That's not too esoteric IMHO. Yeah, finger is kind of a multi-purpose tool. It can show logged-in users as well as fetch info about any user. Without it, you can use who/w to see logged-in users and getent passwd foo to fetch user info (and parse it yourself). For that matter, except for the network finger protocol (which as mentioned, is pretty much dead, except for the ever-popular BOFH server at b...@wisc.edu), it would be fairly easy to replace finger with a shell script that calls the above based on the arguments. Even the network side could be done (with no error checking) in bash with: (echo -e 'bofh\r' 10; cat) /dev/tcp/wisc.edu/finger -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Thu, Jan 10, 2013 at 03:08:21PM -0500, Bill Nottingham wrote: Seth Vidal (skvi...@fedoraproject.org) said: Fun fact™: I learned from this conversation that my default personal user environment still contains a .plan file. What was in your plan? Why, the same thing we do every night, Pinky... bridge-utils is needed to configure bridges, and is small. You can create a bridge with /sbin/ip, but not add interfaces to it. Your patch (https://lwn.net/Articles/289040/ ) should rectify this. Wasn't the patch merged? -- Tomasz TorczTo co nierealne -- tutaj jest normalne. xmpp: zdzich...@chrome.pl Ziomale na życie mają tu patenty specjalne. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Thu, 10 Jan 2013 15:08:21 -0500 Bill Nottingham nott...@redhat.com wrote: ...snip... In any case, attached is the initial diff I have. Some additional ideas, and reasons why I may have left things Iin that were suggested to remove... bind-utils in core? Probibly for nslookup/dig. I'm fine leaving that in there. ...snip... Much like pinfo/info, there is mtr and traceroute. As a philosophy, should we by default be including 'better' versions of ancient unix tools instead of the standard ones? If so, we would be leaving lftp in and taking ftp out? I'm fine dropping both, and in the info case, leaving info for directory ownership and dropping pinfo. We should probably split off network auth, network filesystem tools, and smart card auth, into their own separate groups. Makes sense. ...snip... prelink. Ugh. ok, I guess I could try again. Can we remove prelink? What does it get us these days? smartmontools... could be dropped, if people don't use it much. All it does out of the box is e-mail root (and throw messages at the tty.) smartctl is handy for troubleshooting... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On 01/10/2013 03:08 PM, Bill Nottingham wrote: smartmontools... could be dropped, if people don't use it much. All it does out of the box is e-mail root (and throw messages at the tty.) smartmontools brings in smartctl which starts and displays status from SMART tests. The replacement is I guess libatasmart (sktest/skdump), but it's not quite satisfactory yet: - smartctl -t reports how long the test will take, sktest doesn't - smartctl -a reports past test results, skdump doesn't AFAIK - there's very little in the way of man pages/docs for skdump - I have seen cases where smartctl works across the USB interface but skdump doesn't---although the reverse was more common and recently both seem to work equally well. In summary, libatasmart is not yet a fully satisfactory replacement for this arguably important functionality. I would be willing to work with Lennart on addressing those, if there's consensus to dump smartmontools. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Tomasz Torcz wrote: On Thu, Jan 10, 2013 at 03:08:21PM -0500, Bill Nottingham wrote: Seth Vidal (skvidal at fedoraproject.org) said: Fun fact™: I learned from this conversation that my default personal user environment still contains a .plan file. What was in your plan? Why, the same thing we do every night, Pinky... bridge-utils is needed to configure bridges, and is small. You can create a bridge with /sbin/ip, but not add interfaces to it. Your patch (https://lwn.net/Articles/289040/ ) should rectify this. Wasn't the patch merged? It's done with bridge, in iproute2: https://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=tree;f=bridge Also ifenslave, in iputils-rpm, is deprecated. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
bridge-utils is needed to configure bridges, and is small. You can create a bridge with /sbin/ip, but not add interfaces to it. The other quirk about iproute (Which contains /sbin/ip) is that netstat is in net-tools which also contains ifconfig. Would be nice to have that separated, since iproute is the future. -- Sincerely, William Brown pgp.mit.edu http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x3C0AC6DAB2F928A2 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Once upon a time, Bill Nottingham nott...@redhat.com said: Some additional ideas, and reasons why I may have left things Iin that were suggested to remove... Okay, that's a starting point. However, what is the reasoning behind this? There are a number of things in your list of removed things that are still quite useful and not redundant. Before this really goes anywhere, what is the justification for what goes (and what stays in for that matter)? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Fri, 11 Jan 2013 07:53:19 +1030 William Brown will...@firstyear.id.au wrote: bridge-utils is needed to configure bridges, and is small. You can create a bridge with /sbin/ip, but not add interfaces to it. The other quirk about iproute (Which contains /sbin/ip) is that netstat is in net-tools which also contains ifconfig. Would be nice to have that separated, since iproute is the future. Whats wrong with 'ss' ? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On 10 January 2013 15:10, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Bill Nottingham nott...@redhat.com said: Some additional ideas, and reasons why I may have left things Iin that were suggested to remove... Okay, that's a starting point. However, what is the reasoning behind this? There are a number of things in your list of removed things that are still quite useful and not redundant. Before this really goes anywhere, what is the justification for what goes (and what stays in for that matter)? Remember this is removal from core NOT from the distribution.. To quote the original email (Oh, and to clarify this: it's just about what to install by default, not about what to ship. It's just that I have a hard time remembering when i saw the last laptop with irda or pcmcia ports, and maybe we should not install that anymore by default...) -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Tomasz Torcz (to...@pipebreaker.pl) said: On Thu, Jan 10, 2013 at 03:08:21PM -0500, Bill Nottingham wrote: Seth Vidal (skvi...@fedoraproject.org) said: Fun fact™: I learned from this conversation that my default personal user environment still contains a .plan file. What was in your plan? Why, the same thing we do every night, Pinky... bridge-utils is needed to configure bridges, and is small. You can create a bridge with /sbin/ip, but not add interfaces to it. Your patch (https://lwn.net/Articles/289040/ ) should rectify this. Wasn't the patch merged? No, upstream maintainers would rather people use netlink. (Unless something has changed since then.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Chris Adams (cmad...@hiwaay.net) said: Once upon a time, Bill Nottingham nott...@redhat.com said: Some additional ideas, and reasons why I may have left things Iin that were suggested to remove... Okay, that's a starting point. However, what is the reasoning behind this? There are a number of things in your list of removed things that are still quite useful and not redundant. Before this really goes anywhere, what is the justification for what goes (and what stays in for that matter)? Sure, going through the diff: - packagereqbc/packagereq - packagereqdump/packagereq - packagereqed/packagereq - packagereqfinger/packagereq - packagereqftp/packagereq - packagereqrdate/packagereq - packagereqrsh/packagereq - packagereqtalk/packagereq - packagereqtelnet/packagereq - packagereqypbind/packagereq Moved to legacy-unix. - packagereqcyrus-sasl-plain/packagereq Should be Required: by apps that need it. - packagereqdbus/packagereq Pulled in implicitly by @core, moved there to be explicit. - packagereqlogrotate/packagereq Required: by rsyslog. Not used if you're not using rsyslog. - packagereqntsysv/packagereq Doesn't do much useful these days with systemd migration. (chkconfig has redirects; this does not.) - packagereqtmpwatch/packagereq Out of the box, conflicts with systemd's own tmp reaper. For apps that ship additional tmpwatch dirs (cups, etc.) they require it. - packagereqbtrfs-progs/packagereq Will be installed by anaconda if you install on btrfs; can move to @core if it becomes the default FS. - packagereqcoolkey/packagereq - packagereqpam_pkcs11/packagereq Will move to a smart-card-auth group shortly. - packagereqdmraid/packagereq Will be installed by anaconda if you need it. - packagereqfprintd-pam/packagereq Pulled in the GNOME desktop environment; doesn't need to be in the smaller server installs. - packagereqirda-utils/packagereq Ancient cruft. - packagereqlftp/packagereq Removed; ftp is in legacy-unix. - packagereqmdadm/packagereq Will be installed by anaconda if you need it (and pulled in by udisks2 if you install that.) - packagereqpasswdqc/packagereq Not used in the default config any more (libpwquality is used.) - packagereqpcmciautils/packagereq Ancient cruft (for old 16-bit only slots.) - packagereqpm-utils/packagereq See Lennart's reasoning on this. I could be swayed, or convinced that we should provide compat 'pm-suspend/pm-hibernate' binaries that just link to systemctl. - packagereqrdist/packagereq Doesn't belong in @standard; possibly should be in legacy-unix, or some other 'random administration utilities' section. - packagereqstunnel/packagereq - packagereqtree/packagereq Not functionality needed by everyone out of the box. - packagereqtime/packagereq bash has this builtin; don't think the additional features warrant this on every non-minimal install. - packagereqvconfig/packagereq Functionality subsumed by /sbin/ip. - packagereqwget/packagereq curl is already in the minimal install. (This will get pulled in by a bunch of other packages in Fedora anyway.) - packagereqwireless-tools/packagereq Functionality subsumed by iw. Although this is perhaps premature until initscripts gets ported to it. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
On Thu, 2013-01-10 at 15:14 -0700, Kevin Fenzi wrote: On Fri, 11 Jan 2013 07:53:19 +1030 William Brown will...@firstyear.id.au wrote: bridge-utils is needed to configure bridges, and is small. You can create a bridge with /sbin/ip, but not add interfaces to it. The other quirk about iproute (Which contains /sbin/ip) is that netstat is in net-tools which also contains ifconfig. Would be nice to have that separated, since iproute is the future. Whats wrong with 'ss' ? kevin Nothing I didn't know about it. Will read into it now. Maybe this shows that a documentation component is needed, to bridge the gap to say X tool is replaced by Y IE netstat - ss -- Sincerely, William Brown pgp.mit.edu http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x3C0AC6DAB2F928A2 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: comps' standard group spring cleaning?
Chris Adams wrote: Once upon a time, Lennart Poettering mzerq...@0pointer.de said: But I'll bite anyway: we hardly need two info readers installed by default, do we? Well, I'd agree with that. The problem (again IMHO) with info is that it works for emacs users (or at least that's what I guess, I never can figure it out), while pinfo operates more like a console web browser (such as lynx). However, you can't remove info, because it provides /sbin/install-info (which is required by every package that provides info files). I still think pinfo should stay. +1, the default info is really a PITA to use, pinfo is much better. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
