I said it and now I'm doing it.
I have started making a once over of the packages looking for dead/obsolete/unecessary core packages in core-testing. I have gone through .src.rpm's a*-e* and I have a breakdown of packages. These packages appear to be things that can either move to extras or be dropped.
I am willing to pledge support for some of these packages if there is a call for their continued existance in extras, but not all. I have a feeling that some will drop completly out from lack of support.
Lines with a '+' mean that they are a dependancy that is a logical remove as well. I have a small reason for each removal from core listed next to each. 'D:0' = nothing depends on these packages.
Highly likley candidates
ElectricFence - Development only ( many similar ) D:0 SDL* - kdeaddons is the only thing that depends on this + kdeaddons - small add on packages for stock kde apps *VFlib2 - only if we can break the ghostscript requireedby + MagicPoint - Duplicated functionality already in other packages Xaw3d - required by emacs + emacs ( pick emacs or xemacs and move the other to extras ) a2ps - used by Xfprint ( XFce - already moved to extras ) awesfx - OLD Soundblaster awe 32 util ( 2000 ) D:0 bogl* - kernel 2.2 fb graphics lib D:0 cdecl - C/C++ to English conversion D:0 dasher - obscure alternate input method D:0 ! 10MB dovecot - IMAP server ( duplication of effort ) epic - duplicate effort lynx - duplicate effort ( elinks )
Possible candidates
Canna - Superceeded by IIMF - nothing depends ! 10MB Guppi apel - extras for emacs + ddskk - extra input methods for emacs + film - message encoding emacs + wl - imap/pop/nntp reader for emacs arptables_jf - specialized filtering of arp D:0 ccs - cluster config? cdlabelgen - does anyone use? D:0 cscope - c code browser - duplicate effort D:0 doxygen - Sorce code documentation generator D:0 autorun - functionality in most desktops already d:0
Cheers, Eric
On Sat, Feb 26, 2005 at 12:23:41AM -0500, Eric Warnke wrote:
SDL* - kdeaddons is the only thing that depends on this
But a great deal of third-party programs use it. It's nice to have libraries like this in core so there's a relatively normal functional base.
dovecot - IMAP server ( duplication of effort )
Duplication of which effort?
On Sat, Feb 26, 2005 at 12:23:41AM -0500, Eric Warnke wrote:
Highly likley candidates
ElectricFence - Development only ( many similar ) D:0
http://fedora.redhat.com/about/objectives.html
---begin quote--- Objectives of Fedora Core:
1. Create a complete general-purpose operating system with capabilities equivalent to competing operating systems, built for and by a community -- _those who not only consume, but also produce for the good of other community members_. [...] 4. Provide a robust development platform for building software, particularly open source software. ---end quote---
Given the above, I don't see how things like Electric Fence are "likely candidates" for removal. I'm not saying FC must keep Electric Fence, but "Development only" is not by itself a reason to remove it or any package. At least, that's how I see things.
-Barry K. Nathan barryn@pobox.com
On 02/25/2005 09:23:41 PM, Eric Warnke wrote:
- emacs ( pick emacs or xemacs and move the other to extras )
keep emacs, move xemacs.
lynx - duplicate effort ( elinks )
keep lynx - a lot of existing scripts depend upon it, lynx really is almost as standard on *nix as vi - it is THE cli http client.
Ville Skyttä ville.skytta@iki.fi writes:
On Sat, 2005-02-26 at 06:27 +0000, Michael A. Peters wrote:
On 02/25/2005 09:23:41 PM, Eric Warnke wrote:
- emacs ( pick emacs or xemacs and move the other to extras )
keep emacs, move xemacs.
Already done. XEmacs and related stuff will be soon imported to Extras CVS for FC4+.
Would you consider moving only xemacs-sumo (about 3/4 of the whole thing) and keep the core xemacs? FWIW, since someone has voiced a "keep emacs, move xemacs" preference I'd like to register the opposite suggestion ;-).
On Sat, Feb 26, 2005 at 06:27:52AM +0000, Michael A. Peters wrote:
lynx - duplicate effort ( elinks )
keep lynx - a lot of existing scripts depend upon it, lynx really is almost as standard on *nix as vi - it is THE cli http client.
Is elinks command-line compatible to lynx? It it is, I would prefer to see elinks, as it renders pages much better (supports frames and tables, etc).
On Sat, Feb 26, 2005 at 12:31:43PM -0500, Chuck R. Anderson wrote:
Is elinks command-line compatible to lynx? It it is, I would prefer to see elinks, as it renders pages much better (supports frames and tables, etc).
Honestly, that's why I like to have lynx around: "what would this look like to someone who for accessability reasons needs to use a tool that can't handle frames?".
It's best to use real screen readers as tests, since many of them handle quite a bit of markup these days. Many gecko tools also give you stlye-less views or degraded viewing of pages.
I'm also just suggesting that these move to extras, not gone all together.
Matthew Miller wrote:
Honestly, that's why I like to have lynx around: "what would this look like to someone who for accessability reasons needs to use a tool that can't handle frames?".
On 02/26/2005 09:48:03 AM, Matthew Miller wrote:
Honestly, that's why I like to have lynx around: "what would this look like to someone who for accessability reasons needs to use a tool that can't handle frames?".
lynx does handle frames. It also handles some CSS. It's a great browser to have on a headless box, and one that a lot of admins of headless boxes expect to be there.
On Sat, 2005-02-26 at 12:31 -0500, Chuck R. Anderson wrote:
On Sat, Feb 26, 2005 at 06:27:52AM +0000, Michael A. Peters wrote:
lynx - duplicate effort ( elinks )
keep lynx - a lot of existing scripts depend upon it, lynx really is almost as standard on *nix as vi - it is THE cli http client.
Is elinks command-line compatible to lynx? It it is, I would prefer to see elinks, as it renders pages much better (supports frames and tables, etc).
Agree, elinks features:
* Lots of protocols (local files, finger, http, https, ftp, smb, ipv4, ipv6) * Authentication (HTTP authentication, Proxy authentication) * Persistent cookies * Cute menus and dialogs * Tabbed browsing * Support for browser scripting (Perl, Lua, Guile) * Tables and frames rendering * Colors * Background (non-blocking) downloads
... and really active upstream developers.
Karel
On Feb 26, 2005, Eric Warnke eric@snowmoon.com wrote:
dovecot - IMAP server ( duplication of effort )
What's the other IMAP/POP server in Core that can export mailboxes in the standard mbox format as delivered by the default MTA, and can do preauth when started from the command line for fetchmail over ssh?
epic - duplicate effort
Is there any other text-mode IRC client in Core?
lynx - duplicate effort ( elinks )
This debate has already happened several times. IIRC the end conclusion is always that each of the text-mode browsers has strengths and weaknesses that the others don't, to a point in which we really shouldn't drop any of them.
- film - message encoding emacs
I suppose you mean flim
On Sat, 2005-02-26 at 03:37 -0300, Alexandre Oliva wrote:
epic - duplicate effort
Is there any other text-mode IRC client in Core?
I've proposed its replacement with irssi before. It was generally agreed upon on this list...
pvrabec: mind moving epic to Extras, and irssi from Extras into Core?
Thanks
I don't mind. Some people in Brno office will invite this replacement.
Colin Charles wrote:
On Sat, 2005-02-26 at 03:37 -0300, Alexandre Oliva wrote:
epic - duplicate effort
Is there any other text-mode IRC client in Core?
I've proposed its replacement with irssi before. It was generally agreed upon on this list...
pvrabec: mind moving epic to Extras, and irssi from Extras into Core?
Thanks
Alexandre Oliva wrote:
On Feb 26, 2005, Eric Warnke eric@snowmoon.com wrote:
dovecot - IMAP server ( duplication of effort )
What's the other IMAP/POP server in Core that can export mailboxes in the standard mbox format as delivered by the default MTA, and can do preauth when started from the command line for fetchmail over ssh?
I use dovecot to export mail delivered in maildir format. Don't know about mbox - but you're not suggesting that cyrus exports standard format, are you? cyrus runs its own database - one reason I don't use it.
Neal Becker wrote:
I use dovecot to export mail delivered in maildir format. Don't know about mbox - but you're not suggesting that cyrus exports standard format, are you? cyrus runs its own database - one reason I don't use it.
Mbox is completely supported . I use it to export my mbox files from thunderbird (windows version) to evolution (I know it's weird , but I have plans of doing this to use webmail later while I dont get a server).
-- Pedro Macedo
On Feb 28, 2005, Neal Becker ndbecker2@verizon.net wrote:
Alexandre Oliva wrote:
On Feb 26, 2005, Eric Warnke eric@snowmoon.com wrote:
dovecot - IMAP server ( duplication of effort )
What's the other IMAP/POP server in Core that can export mailboxes in the standard mbox format as delivered by the default MTA, and can do preauth when started from the command line for fetchmail over ssh?
I use dovecot to export mail delivered in maildir format. Don't know about mbox - but you're not suggesting that cyrus exports standard format, are you?
Nope. I'm suggesting it doesn't, and therefore dovecot is not duplicate effort, it stands on its own.
cyrus runs its own database - one reason I don't use it.
Yup, same here.
On Sat, Feb 26, 2005 at 12:23:41AM -0500, Eric Warnke wrote:
I said it and now I'm doing it.
Thanks! Most of the list looks very reasonable (to me personally, at least).
bogl* - kernel 2.2 fb graphics lib D:0
Used in the installer for CJK support in "text mode"
doxygen - Sorce code documentation generator D:0
A build dependency of several packages (e.g. kdelibs) Mirek
Round two of the first set of possibilities. I have marked objections and removed a few from consiteration. Any with objections that I have kept, I have expanded on my reasoning. Once again these are suggestions to the community and I have no power to make the cuts myself, but once the discussion is complete I will forward the annotaded recommendationd up the food chain.
In responding, please comment if you want it kept in core or in extras and why.
Removed from consiteration Xaw3d - required by emacs and emacs is being kept bogl* - kernel 2.2 fb graphics lib d:0 ( should update dependancies here if it's required by the installer! ) epic/irssi? epic is there and it's the only text mode irc client unless we want to swap it out for irssi
Ojections, but I still believe could be moved.
dovecot - IPAP server - 2 objections, but if you can server to the internet, you can download it from extras. Ether this or cyrus should be cut.
ElectricFence - Development only nothing depends on it - 1 objection, but I still say it's usage does not justify it remaining in core - there is at least one competing package ( dmalloc, valgrind )
lynx/elinks - 1 objection about scripts using lynx... ether those scripts are not part of core or they are not marked correctly. If you can surf the web with either, you can download them from extras. If either has a dependancy in core the .src.rpm needs to be corrected.
doxygen - Sorce code documentation generator D:0 - 1 objecton - I don't think we necessarly need to keep every build dependancy in core.
Likley without objections SDL* - kdeaddons is the only thing that depends on this + kdeaddons - small add on packages. not 100% necessary Canna - Superceeded by IIMF - nothing depends ! 10MB MAKEDEV - Superceeded by udev ? *VFlib2 - Required by MajicPoint and ghostscript - only if we can break the ghostscript compatibility + MagicPoint - Duplicated functionality already in other packages a2ps - text to postscript tool required by xfprint awesfx - OLD ( 2000 ) D:0 cdecl - C/C++ to English conversion D:0 dasher - obscure alternate input method ! 10MB apel - extras for emacs + ddskk - extra input methods for emacs + flim - message encoding emacs + wl - imap/pop/nntp reader arptables_jf - specialized filtering of arp D:0 cscope - c code browser - duplicate effort D:0
Possible without objections Guppi ccs - cluster config? cdlabelgen - does anyone use? D:0 autorun - functionality in most desktops already d:0
More to follow....
Cheers, Eric
"SDL* - kdeaddons is the only thing that depends on this" dropping sdl isn't a good idea because many third party apps require it.
On Sat, 2005-02-26 at 14:49 +0100, dragoran wrote:
"SDL* - kdeaddons is the only thing that depends on this" dropping sdl isn't a good idea because many third party apps require it.
+1 I agree that removing most games (except the basic as gnome-games) from FC is desirable however removing SDL would mean that even for installing almost any games this dependency would have to be installed by user. I don't think it's a good idea.
man, 28.02.2005 kl. 10.13 skrev Tomas Mraz:
On Sat, 2005-02-26 at 14:49 +0100, dragoran wrote:
"SDL* - kdeaddons is the only thing that depends on this" dropping sdl isn't a good idea because many third party apps require it.
+1 I agree that removing most games (except the basic as gnome-games) from FC is desirable however removing SDL would mean that even for installing almost any games this dependency would have to be installed by user. I don't think it's a good idea.
SDL isn't only used by games, but also as an A/V output system by many (3.party) progs. Please keep SDL - it is a really usefull libary.
BTW, we must decide wether Fedora (core+extras(+livna)) should be self-containing, or if it should be as easy as possible to use as a platform for 3. party programs. I think it should be made as easy as possible to use as a platform, and not depend on the "all programs MUST come from RH/extras or they ar EVIL!" thinking we are seeing now...
Kyrre
[snip]
BTW, we must decide wether Fedora (core+extras(+livna)) should be self-containing, or if it should be as easy as possible to use as a platform for 3. party programs. I think it should be made as easy as possible to use as a platform, and not depend on the "all programs MUST come from RH/extras or they ar EVIL!" thinking we are seeing now...
then a lot of third part packagers should do a better job of packaging. myself included.
Kyrre Ness Sjobak wrote:
BTW, we must decide wether Fedora (core+extras(+livna)) should be self-containing, or if it should be as easy as possible to use as a platform for 3. party programs. I think it should be made as easy as possible to use as a platform, and not depend on the "all programs MUST come from RH/extras or they ar EVIL!" thinking we are seeing now...
Kyrre
Where are you seeing that? You are seeing a discussion of Fedora Core/Extras development. 3rd party development discussions are elsewhere. 3rd party programs are welcomed.
ons, 02.03.2005 kl. 19.40 skrev Demond James:
Kyrre Ness Sjobak wrote:
BTW, we must decide wether Fedora (core+extras(+livna)) should be self-containing, or if it should be as easy as possible to use as a platform for 3. party programs. I think it should be made as easy as possible to use as a platform, and not depend on the "all programs MUST come from RH/extras or they ar EVIL!" thinking we are seeing now...
Kyrre
Where are you seeing that? You are seeing a discussion of Fedora Core/Extras development. 3rd party development discussions are elsewhere. 3rd party programs are welcomed.
No it's just the common mentality i am seeing on these lists - if a lib isn't required for anything in core, drop it as fast as possible!
On Sat, Feb 26, 2005 at 08:38:51AM -0500, Eric Warnke wrote:
ElectricFence - Development only nothing depends on it - 1 objection, but I still say it's usage does not justify it remaining in core - there is at least one competing package ( dmalloc, valgrind )
valgrind is i386 only (therefore not a replacement for efence) and dmalloc is far worse then efence. If anything needs to be dumped to Extras, then it is dmalloc, not ElectricFence.
lynx/elinks - 1 objection about scripts using lynx... ether those scripts are not part of core or they are not marked correctly. If you can surf the web with either, you can download them from extras. If either has a dependancy in core the .src.rpm needs to be corrected.
If you install a server, you often don't run X at all and ability to browse web is very useful. Plus it is definitely something e.g. blind people can't miss in the distro. Therefore I strongly object to dropping at least elinks. elinks is really small package btw.
doxygen - Sorce code documentation generator D:0 - 1 objecton - I don't think we necessarly need to keep every build dependancy in core.
Core must be self-hosting.
Jakub
Jakub Jelinek wrote:
On Sat, Feb 26, 2005 at 08:38:51AM -0500, Eric Warnke wrote:
ElectricFence - Development only nothing depends on it - 1 objection, but I still say it's usage does not justify it remaining in core - there is at least one competing package ( dmalloc, valgrind )
valgrind is i386 only (therefore not a replacement for efence) and dmalloc is far worse then efence. If anything needs to be dumped to Extras, then it is dmalloc, not ElectricFence.
Yes yes yes and yes.
Round 3... all cage rule apply.. new items on the lists
Removed from consiteration *electricfence - multiplatform .. see new additions* *doxygen - core must be self hosting* Xaw3d - required by emacs and emacs is being kept bogl* - kernel 2.2 fb graphics lib d:0 ( should update dependancies here if it's required by the installer! ) epic/irssi? epic is there and it's the only text mode irc client unless we want to swap it out for irssi
Ojections, but I still believe could be moved.
dovecot - IPAP server - 2 objections, but if you can server to the internet, you can download it from extras. Ether this or cyrus should be cut.
*lynx/elinks - 1 objection about scripts using lynx... ether those scripts are not part of core or they are not marked correctly. If you can surf the web with either, you can download them from extras. If either has a dependancy in core the .src.rpm needs to be corrected. Personally I think lynx should go to extras.*
*SDL - kdeaddons is the only thing that depends on this. 1 objection. Would be nice to have in core, but is really not a core function since nothing in core depends on it. Anything that is going to require it can pull it down from extras.* + kdeaddons - small add on packages. not 100% necessary.
*New additions to the likley list* dmalloc, valgrind - electricence appears to be more compatible and better developed. freeglut - library with no dependancy in core fsh - obscure shell, features absorbed into OpenSSH giftrans - netpbm tools can do the same iptstate - package getting stale jed - another text mode editor joe - yet another text editor ( nano / pico / emacs / ed / vi ) lftp - useful ftp client ( ftp, ncftp ) D:0
Likley without objections Canna - Superceeded by IIMF - nothing depends ! 10MB MAKEDEV - Superceeded by udev ? *VFlib2 - Required by MajicPoint and ghostscript - only if we can break the ghostscript compatibility + MagicPoint - Duplicated functionality already in other packages a2ps - text to postscript tool required by xfprint awesfx - OLD ( 2000 ) D:0 cdecl - C/C++ to English conversion D:0 dasher - obscure alternate input method ! 10MB apel - extras for emacs + ddskk - extra input methods for emacs + flim - message encoding emacs + wl - imap/pop/nntp reader arptables_jf - specialized filtering of arp D:0 cscope - c code browser - duplicate effort D:0
Possible without objections Guppi ccs - cluster config? cdlabelgen - does anyone use? D:0 autorun - functionality in most desktops already d:0 freeradius - complex package d:0 ftpcopy - utility D:0. I have never used it, do we need in core g-wrap - Another wrapper for a development utility d:0 h2ps - another postscript generator D:0
Cheers, Eric
On Sat, 26 Feb 2005 09:24:40 -0500, Eric Warnke eric@snowmoon.com wrote:
freeglut - library with no dependancy in core
Cough in the developmnent tree....libtiff rpm -q --requires libtiff libglut.so.3 rpm -q --whatprovides libglut.so.3 freeglut-2.2.0-14
how are you checking for deps? the libtiff deps isnt somthing obscure.. its required by gtk2. I just want to make sure you aren't wasting your time using a depcheck method thats going to be highly unreliable. Are you looking at the deps in fc3 or in rawhide? I'm not sure looking at the dep chains in fc3 gives an accurate picture for the sake of this discussion.
dasher - obscure alternate input method ! 10MB
uhm... thats almost an offensive comment... a11y elements are very important... just be glad you don't need them.
Possible without objections Guppi
used by gnucash.... how are you checking for deps? Even in fc3 this is a requirement. rawhide: libguppi.so.16 is needed by (installed) gnucash-1.8.11-1.i386 libguppitank.so.16 is needed by (installed) gnucash-1.8.11-1.i386 fc3: libguppi.so.16 is needed by (installed) gnucash-1.8.9-2.i386 libguppitank.so.16 is needed by (installed) gnucash-1.8.9-2.i386
ccs - cluster config?
if you don't understand the function perhaps its best not to list as being removable.
freeradius - complex package d:0
how is complexity a reason to drop it? apache is pretty complex as well. either make the duplication argument or make the argument that its unneeded in core.
h2ps - another postscript generator D:0
Are you saying that other cli postscript generators can convert Hangul and thus overlap in functionality?
-jef
Jeff,
This was meant to spark discussion... not to be the end all be all.
Jeff Spaleta wrote:
how are you checking for deps? the libtiff deps isnt somthing obscure.. its required by gtk2. I just want to make sure you aren't wasting your time using a depcheck method thats going to be highly unreliable. Are you looking at the deps in fc3 or in rawhide? I'm not sure looking at the dep chains in fc3 gives an accurate picture for the sake of this discussion.
I could not find a rpmdb for rawhide. If you wish to send me one I would be more than happy to use it. I have been using rpm -w --whatrequires under the full fc3 rpmdb.
dasher - obscure alternate input method ! 10MB
uhm... thats almost an offensive comment... a11y elements are very important... just be glad you don't need them.
If it is used by kde or gnomes accessability feature and used by someone ( anyone ) I will remove it from consiteration.
Your other objections are noted, but I stand by freeradius as a specialty package probably better served in extras.
Cheers, Eric
On Sat, 26 Feb 2005 10:17:12 -0500, Eric Warnke eric@snowmoon.com wrote:
If it is used by kde or gnomes accessability feature and used by someone ( anyone ) I will remove it from consiteration.
I'm pretty sure the entire point of dasher is related to accessibility.
man dasher ... Control mode Provides a control node at the bottom of the screen. This allows various tasks to be performed inside Dasher, such as editing the text written, speaking entered text and stopping or pausing Dasher. If compiled with and using a desktop supporting the ATK accessibility framework, compliant applications will have their menu trees exported to Dasher and these may be accessed via this node.
As soon as you play with it.. and configure it to enable the control mode...you'll see control elements apear in the interface and not just alphabet.
-jef
Please post feedback. All objections noted. Please tell me why any of these items should stay in core. Most should probably end up in extras with a few that can probably drop off all together at this point. This list was based on my own review of .src.rpm's in testing. I am not running testing, so ther may be small issues with some of the items, please contact me directly if I miscalculated.
This is based on core being a small and stable platform with little diplication. Many pacakages would probably do better in extras too with the possibility of more maintainers.
Once I have sufficient feedback I will forward this list on to the technical board for consiteration.
Please positive feedback only.
Removed from consiteration ccs - cluster config? Guppi electricfence - multiplatform .. see new additions doxygen - core must be self hosting Xaw3d - required by emacs and emacs is being kept bogl* - kernel 2.2 fb graphics lib d:0 ( should update dependancies here if it's required by the installer! ) epic/irssi? epic is there and it's the only text mode irc client unless we want to swap it out for irssi dasher - alternate input method h2ps - should let people that use multinational tools decide which one go and which ones stay
Ojections, but I still believe could be moved.
*freeglut - library with no dependancy in core. libtiff requirement can be corrected. I am working on a patch or updated spec file.*
*dovecot/cryus - IMAP server cyrus does seem more like a specialty package when compared to the simplcity and utility of dovecot.*
lynx/w3m+w3m-el/elinks - 1 objection about scripts using lynx... ether those scripts are not part of core or they are not marked correctly. If you can surf the web with either, you can download them from extras. If either has a dependancy in core the .src.rpm needs to be corrected. Personally I think lynx should go to extras.
SDL - kdeaddons is the only thing that depends on this. 1 objection. Would be nice to have in core, but is really not a core function since nothing in core depends on it. Anything that is going to require it can pull it down from extras. + kdeaddons - small add on packages. not 100% necessary.
*New additions to the likley list* w3m/w3m-el - another text pager/web browser usermode/utempter - overlaps with sudo tora - packaged without oracle plugin and does appear to work out of the box with MySQL or postgress. tix - Tcl/Tk extansion routed - appears to be superceeded by quagga qmkbootdisk - graphical boot disk creation utiltiy - stale ots - was used as part of abiword, but abiword has been religated to extras nut - nice package, but is it really core materal? nss_db - partly broken. Most usefulness gone now that nscd is standard ( I will personally manage since I wrote the fix ) dosfttools - looks like mtools superceeds this package. mew - emailing in emacs strace - looks like ltrace provides same functionality dmalloc, valgrind - electricence appears to be more compatible and better developed. fsh - obscure shell, features absorbed into OpenSSH giftrans - netpbm tools can do the same iptstate - package getting stale jed - another text mode editor joe - yet another text editor ( nano / pico / emacs / ed / vi ) lftp - useful ftp client ( ftp, ncftp ) D:0 nedit - another x text editor
Likley without objections Canna - Superceeded by IIMF - nothing depends ! 10MB MAKEDEV - Superceeded by udev ? *VFlib2 - Required by MajicPoint and ghostscript - only if we can break the ghostscript compatibility + MagicPoint - Duplicated functionality already in other packages a2ps - text to postscript tool required by xfprint awesfx - OLD ( 2000 ) D:0 cdecl - C/C++ to English conversion D:0 apel - extras for emacs + ddskk - extra input methods for emacs + flim - message encoding emacs + wl - imap/pop/nntp reader arptables_jf - specialized filtering of arp D:0 cscope - c code browser - duplicate effort D:0
Possible without objections talk - protocol is getting old with IM star - tar with acl support. planner - anther project managment tool pinfo - another text info file browser - do we need two? cdlabelgen - does anyone use? D:0 autorun - functionality in most desktops already d:0 freeradius - complex package d:0 ftpcopy - utility D:0. I have never used it do we need in core g-wrap - Another wrapper for a development utility d:0 mc - Is this really a core util? would it be better served in extras?
Cheers, Eric
On Sat, 2005-02-26 at 12:24 -0500, Eric Warnke wrote:
fsh - obscure shell, features absorbed into OpenSSH
Some scripts will use this but relatively few. This is one of the cases where the FC3 package doesn't actually work on FC4, though -- it'll break in an upgrade.
I'd like to see it die in FC5 -- OpenSSH needs to completely provide the same functionality first though. OpenSSH doesn't yet have the capacity to automatically decide whether to be the 'master' and open the first connection, or whether to be the 'slave' and use an existing connection. Neither does it hold the connection open with a timeout. Not hard to fix -- but since fsh is only 161KiB, it hasn't been a huge priority.
We don't gain much by dropping it, but I'd like to say in the release notes that it's deprecated, so that we can drop it from FC5. Although by FC5 we can just move it into Extras without too much upgrade pain anyway.
On Sat, Feb 26, 2005 at 12:24:18PM -0500, Eric Warnke wrote:
usermode/utempter - overlaps with sudo
Is there a GUI front-end for sudo? (And, ideally, a good API for editing its config file?) These are definitely both different approaches to the same problem, but currently, they both have various strengths and weaknesses. Significant work would have to go into one of them in order to drop one.
Although, since sudo isn't configured by default or used by anything, it's possible *that's* a candidate.
strace - looks like ltrace provides same functionality
nope!
pinfo - another text info file browser - do we need two?
the other one really sucks.
mc - Is this really a core util? would it be better served in extras?
It was the gnome desktop manager before nautilus. I assume that's why it's still around.
On Saturday 26 February 2005 18:39, Matthew Miller wrote:
mc - Is this really a core util? would it be better served in extras?
It was the gnome desktop manager before nautilus. I assume that's why it's still around.
A lot of people use that kind of file manager (and it's AFAICT the only text mode file manager in Core)
On 02/26/2005 09:39:08 AM, Matthew Miller wrote:
Although, since sudo isn't configured by default or used by anything, it's possible *that's* a candidate.
I wouldn't cry if sudo disapeared. What I use it for could be done with the other solutions as well, and may even be better done with the other solutions.
On Sun, 27 Feb 2005 20:25:36 +0000, Michael A. Peters mpeters@mac.com wrote:
On 02/26/2005 09:39:08 AM, Matthew Miller wrote:
Although, since sudo isn't configured by default or used by anything, it's possible *that's* a candidate.
I wouldn't cry if sudo disapeared. What I use it for could be done with the other solutions as well, and may even be better done with the other solutions.
We use sudo extensively on every unix system we have. If you've got more than one person doing sysadmining on a machine, it's essential.
If I wanted to spend time tracking down and installing all the basic things I need to make a system where I can be productive, I'd install Solaris, not Linux.
On Mon, Feb 28, 2005 at 09:01:31AM -0500, Paul A. Houle wrote:
If I wanted to spend time tracking down and installing all the basic things I need to make a system where I can be productive, I'd install Solaris, not Linux.
Moving it to extras shouldn't require any "tracking down".
Hi
We use sudo extensively on every unix system we have. If you've got more than one person doing sysadmining on a machine, it's essential.
If I wanted to spend time tracking down and installing all the basic things I need to make a system where I can be productive, I'd install Solaris, not Linux.
I dont support removing sudo either but yum install sudo isnt a hard thing to do. if you are going to jump operating systems just because of this then thats overreacting IMO
===== Regards Rahul Sundaram
__________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo
On Mon, 28 Feb 2005 06:04:46 -0800 (PST), Rahul Sundaram rahulsundaram@yahoo.co.in wrote:
I dont support removing sudo either but yum install sudo isnt a hard thing to do. if you are going to jump operating systems just because of this then thats overreacting IMO
Actually, it's not hard to download the packages and install from source. (./configure ; make ; make install isn't much harder than "yum install" and it's more likely to work.)
However, the whole reason I prefer Linux over Solaris is that Linux comes with a good userspace, not because the Linux kernel is all that good. (The big thing Linux has going for it is driver support.) As the things that I expect to be "just there" start to disappear, the advantages of sticking with Linux go away.
Hi.
"Paul A. Houle" ph18@cornell.edu wrote:
source. (./configure ; make ; make install isn't much harder than "yum install" and it's more likely to work.)
And it's one of the fastest ways to turn a package managed system into an absolute mess unless you know quite well what you're doing.
On 02/28/2005 08:24:20 AM, Ralf Ertzinger wrote:
Hi.
"Paul A. Houle" ph18@cornell.edu wrote:
source. (./configure ; make ; make install isn't much harder than
"yum
install" and it's more likely to work.)
And it's one of the fastest ways to turn a package managed system into an absolute mess unless you know quite well what you're doing.
Absolutely 100% correct. If there isn't an rpm for what I want, I make one myself for that very reason - RPM is one of the biggest strengths of Red Hat (and Fedora) - why mess up a good thing?
I've been down that road before - once you start building from source, you have to keep doing it because rpm doesn't know about what is installed by source, or use --nodeps - the system just becomes difficult to maintain, especially if the box later becomes someone elses job to maintain.
and no, ./configure && make && su --command="make install" is not more likely to work than "yum install packagename"
That is only the case if you mix repo's not designed to work together. Even then, though, software like smart can often sort things out enough to do it.
Hi
Actually, it's not hard to download the packages and install from source. (./configure ; make ; make install isn't much harder than "yum install" and it's more likely to work.)
you are completely wrong about that. yum has auto depedency resolver and several other advantages over installing from source. with pup in fc4 it would be even more friendlier
However, the whole reason I prefer Linux over Solaris is that Linux comes with a good userspace, not because the Linux kernel is all that good. (The big thing Linux has going for it is driver support.) As the things that I expect to be "just there" start to disappear, the advantages of sticking with Linux go away.
let me get this straight. if its called fedora core and is in ISO images, its there and if its in fedora extras as rpm packages, it goes away?
===== Regards Rahul Sundaram
__________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250
Once upon a time, Rahul Sundaram rahulsundaram@yahoo.co.in said:
let me get this straight. if its called fedora core and is in ISO images, its there and if its in fedora extras as rpm packages, it goes away?
Hey, let's just put the kernel and a static shell on a CD; you can get the rest over the Internet!
Objectives of Fedora Core: 1. Create a complete general-purpose operating system with capabilities equivalent to competing operating systems, ... ... 6. Emphasize usability and a "just works" philosophy in selecting default configuration and designing features. ... 8. Include a range of popular packages, beyond those included in Red Hat's commercially supported products. (Limited, of course, to packages that Red Hat can legally provide; also limited to quality packages as defined by our standards.) ...
If the plan is to chuck everything possible to Extras, then someone should go update the Objectives. Competing operating systems include sudo or something like it.
--- Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Rahul Sundaram rahulsundaram@yahoo.co.in said:
let me get this straight. if its called fedora
core
and is in ISO images, its there and if its in
fedora
extras as rpm packages, it goes away?
Hey, let's just put the kernel and a static shell on a CD; you can get the rest over the Internet!
yes. something close to this is very useful as a minimalistic installation which many users have been asking for repeatedly
If the plan is to chuck everything possible to Extras, then someone should go update the Objectives. Competing operating systems include sudo or something like it.
I actually agree with you on sudo but telling people that you would change operating systems instead of typing in yum install sudo is silly.
===== Regards Rahul Sundaram
__________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250
On Tue, Mar 01, 2005 at 08:36:50AM -0600, Chris Adams wrote:
Objectives of Fedora Core:
^^^^
Good point. I think this should read "Objectives of the Fedora Project".
On Tue, 2005-03-01 at 08:36 -0600, Chris Adams wrote:
Once upon a time, Rahul Sundaram rahulsundaram@yahoo.co.in said:
let me get this straight. if its called fedora core and is in ISO images, its there and if its in fedora extras as rpm packages, it goes away?
Hey, let's just put the kernel and a static shell on a CD; you can get the rest over the Internet!
Frankly speaking, that's close to I am using Fedora: All I'd need is a CD sufficiently equipped to perform a "basic upgrade/install" and to launch a "yum/apt network install".
Once the "network install" is up, it doesn't matter much in which repository on the net the packages are located.
Ralf
On Sat, Feb 26, 2005 at 12:24:18PM -0500, Eric Warnke wrote:
Please positive feedback only.
<puzzled/> What does this mean?
usermode/utempter - overlaps with sudo
I thought utempter does something completely different...
usermode-gtk provides the "type root password to run system-config-*" in X; while it does "overlap" with sudo, it can't be _replaced_ by sudo.
nut - nice package, but is it really core materal?
It is one of the basic utilities needed on a "serious" server of any kind.
dosfttools - looks like mtools superceeds this package.
The other way around - mounting is more useful than mcopy. But _both_ are required for mkbootdisk.
MAKEDEV - Superceeded by udev ?
Required by udev, actually.
talk - protocol is getting old with IM
UNIX kernel interface is "getting old" too.
planner - anther project managment tool
"Another"? What is the alternative?
g-wrap - Another wrapper for a development utility d:0
Required by gnucash.
(The simplest way to test dependencies of a package against a rpmdb is probably (rpm --dbpath ... -e --test $package). This takes into account all the provides: in a package.) Mirek
On Saturday 26 February 2005 18:42, Miloslav Trmac wrote:
dosfttools - looks like mtools superceeds this package.
The other way around - mounting is more useful than mcopy. But _both_ are required for mkbootdisk.
I thought boot disks are not possibke anyway? Maybe we can remove all of this.
Miloslav Trmac wrote:
talk - protocol is getting old with IM
UNIX kernel interface is "getting old" too.
This proves that there is *no* package you can suggest removing that someone won't object to. It's like we're seeing "Godwin's Law of Shell Scripts" or something.
I think the time for democracy has passed. Someone needs to just unilaterally make a decision and then deal with problems later.
Jamie Zawinski wrote:
Miloslav Trmac wrote:
talk - protocol is getting old with IM
UNIX kernel interface is "getting old" too.
This proves that there is *no* package you can suggest removing that someone won't object to. It's like we're seeing "Godwin's Law of Shell Scripts" or something.
I think the time for democracy has passed. Someone needs to just unilaterally make a decision and then deal with problems later.
You know, there is another alternative that is neither concensus nor dictatorship. We could vote.
On Sat, Feb 26, 2005 at 12:24:18PM -0500, Eric Warnke wrote:
lftp - useful ftp client ( ftp, ncftp ) D:0
I think ncftp should be the one to be removed from Core. lftp has more functionality (http), and is installed by default, whereas ncftp is not installed by default. Also, while ncftp itself is OSS (Clarified Artistic License), other components from the same company are not (NcFTPd server, libNcFTP).
Possible without objections talk - protocol is getting old with IM
vi, ed, and ex are old too. Should we remove them?
star - tar with acl support.
Do tar or pax provide equivalent functionality?
Le samedi 26 février 2005 à 13:08 -0500, Chuck R. Anderson a écrit :
On Sat, Feb 26, 2005 at 12:24:18PM -0500, Eric Warnke wrote:
lftp - useful ftp client ( ftp, ncftp ) D:0
I think ncftp should be the one to be removed from Core. lftp has more functionality (http), and is installed by default, whereas ncftp is not installed by default. Also, while ncftp itself is OSS (Clarified Artistic License), other components from the same company are not (NcFTPd server, libNcFTP).
+1 for keeping lftp and moving ncftp out. This is way overdue.
Regards,
On Sat, Feb 26, 2005 at 07:35:04PM +0100, Nicolas Mailhot wrote:
Le samedi 26 février 2005 ?? 13:08 -0500, Chuck R. Anderson a écrit :
On Sat, Feb 26, 2005 at 12:24:18PM -0500, Eric Warnke wrote:
lftp - useful ftp client ( ftp, ncftp ) D:0
I think ncftp should be the one to be removed from Core. lftp has more functionality (http), and is installed by default, whereas ncftp is not installed by default. Also, while ncftp itself is OSS (Clarified Artistic License), other components from the same company are not (NcFTPd server, libNcFTP).
+1 for keeping lftp and moving ncftp out. This is way overdue.
ncftp can do recursive get/put. Apart from that, lftp is clearly better imho.
On Lun 28 février 2005 0:12, Pozsár Balázs a écrit :
On Sat, Feb 26, 2005 at 07:35:04PM +0100, Nicolas Mailhot wrote:
Le samedi 26 février 2005 ?? 13:08 -0500, Chuck R. Anderson a écrit :
On Sat, Feb 26, 2005 at 12:24:18PM -0500, Eric Warnke wrote:
lftp - useful ftp client ( ftp, ncftp ) D:0
I think ncftp should be the one to be removed from Core. lftp has more functionality (http), and is installed by default, whereas ncftp is not installed by default. Also, while ncftp itself is OSS (Clarified Artistic License), other components from the same company are not (NcFTPd server, libNcFTP).
+1 for keeping lftp and moving ncftp out. This is way overdue.
ncftp can do recursive get/put. Apart from that, lftp is clearly better imho.
So does lftp, unless I've missed something
On Sat, Feb 26, 2005 at 01:08:09PM -0500, Chuck R. Anderson wrote:
Possible without objections talk - protocol is getting old with IM
vi, ed, and ex are old too. Should we remove them?
Probably not. But removing telnetd wouldn't bother me.
Matthew Miller wrote:
On Sat, Feb 26, 2005 at 01:08:09PM -0500, Chuck R. Anderson wrote:
Possible without objections talk - protocol is getting old with IM
vi, ed, and ex are old too. Should we remove them?
Probably not. But removing telnetd wouldn't bother me.
I have not seen talk activly used in a decade, as opposed to vi that I use daily.
Unfortuantly it appears that telnet and telnet-server packages are built from the same rpm making the split impossible.
Cheers,
On Sat, Feb 26, 2005 at 02:46:51PM -0500, Eric Warnke wrote:
I have not seen talk activly used in a decade, as opposed to vi that I use daily.
Unfortuantly it appears that telnet and telnet-server packages are built from the same rpm making the split impossible.
I'm using talk daily. Much better than all the modern (graphical) tools built on (mostly) crap IM protocols.
Eric Warnke wrote:
Unfortuantly it appears that telnet and telnet-server packages are built from the same rpm making the split impossible.
I've seen this objection several times, and it hardly seems insurmountable to me. Why can't you modify the build system to have an explicit list of RPMs to delete just before burning the "Core" CD?
Since the number of packages that have this kind of problem does not seem to be large, the list would not be very long.
Jamie Zawinski wrote:
I've seen this objection several times, and it hardly seems insurmountable to me. Why can't you modify the build system to have an explicit list of RPMs to delete just before burning the "Core" CD?
I think the objection is to splitting an upstream package between two repositories and maintainers.
Cheers,
On Sat, Feb 26, 2005 at 03:25:02PM -0500, Eric Warnke wrote:
I think the objection is to splitting an upstream package between two repositories and maintainers.
In this case, though the upstream was just ripped from BSD, and isn't particularly maintained (no changes to netkit-telnet at the Source URL in five years....)
On Sat, Feb 26, 2005 at 02:46:51PM -0500, Eric Warnke wrote:
Unfortuantly it appears that telnet and telnet-server packages are built from the same rpm making the split impossible.
Not impossible; just more of a pain.
On Sat, 26 Feb 2005 12:24:18 -0500, Eric Warnke eric@snowmoon.com wrote:
usermode/utempter - overlaps with sudo
usermode is acutually used by every system-config tool utempter is needed by libgnome and xorg-x11 packages nothing uses sudo... though i imagine many users do.
tix - Tcl/Tk extansion
required by tkinter.. as soon as tkinter is dropped this will go. without complaint i would imagine
nut - nice package, but is it really core materal?
as much a piece of core as any server oriented package. Get apache booted out first and I'll agree.
nss_db - partly broken. Most usefulness gone now that nscd is standard (
dosfttools - looks like mtools superceeds this package.
needed by mkbootdisk mtools needed by syslinux get the syslinux and the mkbootdisk maintainers to agree on one or the other if possible before talking about removing one of them. Though honestly i don't see how the binaries in mtools superceed the binaries in dosfstools. /sbin/fsck.vfat seems rather important at first glance.
lftp - useful ftp client ( ftp, ncftp ) D:0
if yer gonna drop one drop ftp or ncftp instead.. lftp handles ftp and http,
MAKEDEV - Superceeded by udev ?
required by udev
a2ps - text to postscript tool required by xfprint
xfprint is no longer in the development tree..
freeradius - complex package d:0
I objected.. i continue to object. This is a poor argument. Either point to a package this duplicates or make an argument that this functionality shouldnt be in core. No matter how complex the service is.. it provides functionality for server configurations.
mc - Is this really a core util? would it be better served in extras?
there are many console oriented applications in Core... is there a reason why there should text console filemanager as well? We have console text editors and web browsers... why not a filemanager as well?
-jef
jed - another text mode editor
- we already discussed moving this to extras
joe - yet another text editor ( nano / pico / emacs / ed / vi )
nano doesn't do utf8 afaict, pico isn't in the distribution (it's pine) emacs is almost it's own operating system ed doesn't count and you know it vi is not an editor
I'm fine with moving joe to extras personally but it does fill a place nothing else fills.
-sv
On Sat, 2005-02-26 at 13:26 -0500, Chuck R. Anderson wrote:
On Sat, Feb 26, 2005 at 01:25:47PM -0500, seth vidal wrote:
vi is not an editor
What is it then?
I think it makes music. All I seem to get from it is beeps.
-sv
On 02/26/2005 02:39:22 PM, seth vidal wrote:
I think it makes music. All I seem to get from it is beeps.
LOL! :p
On Sat, Feb 26, 2005 at 01:25:47PM -0500, seth vidal wrote:
I'm fine with moving joe to extras personally but it does fill a place nothing else fills.
I think nowdays for most users kedit/gedit are that place
On Tue, 2005-03-01 at 09:34 -0500, Alan Cox wrote:
On Sat, Feb 26, 2005 at 01:25:47PM -0500, seth vidal wrote:
I'm fine with moving joe to extras personally but it does fill a place nothing else fills.
I think nowdays for most users kedit/gedit are that place
They ain't ASCII-editors, so they, unlike "joe", they don't help you in emergency situations.
kedit and gedit could be moved to Extras without much pain.
Ralf
Hi
kedit and gedit could be moved to Extras without much pain.
bad idea
what GUI text editors are KDE and GNOME users supposed to use?.
===== Regards Rahul Sundaram
__________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250
On Tue, 2005-03-01 at 07:53 -0800, Rahul Sundaram wrote:
Hi
kedit and gedit could be moved to Extras without much pain.
bad idea
what GUI text editors are KDE and GNOME users supposed to use?.
Either pull one of those in Extras, .. or learn to launch a terminal and start an ASCII-editor :-)
.. may-be then they finally realize they don't need one of these GUI- editors ;-)
In emergency situations they will have to use them anyway ... Oh, wait, I forgot, these users will reinstall everything, should the X-server come up, or something else prevent them from logging in "graphically".
Ralf
Ralf Corsepius wrote:
Either pull one of those in Extras, .. or learn to launch a terminal and start an ASCII-editor :-)
Yeah but when people load up X they aren't wasting the memory to continue to do everything in terminals...that's kinda the point...
.. may-be then they finally realize they don't need one of these GUI- editors ;-)
Forcing them to doesn't really make X look that useful to new users, or that friendly either.
In emergency situations they will have to use them anyway ... Oh, wait, I forgot, these users will reinstall everything, should the X-server come up, or something else prevent them from logging in "graphically".
Sure cause they are all too stupid use a web browser and look for a solution. Your view of typical Fedora users is somewhat disheartening. Would you think taking notepad out of Windows would make more people use DOS Edit? Or install someting else?
Look all I'm saying is why take the basic GUI editors out when they don't really take much space and don't take 2 mins to load like OO?
-sb
Ralf
Ralf Corsepius wrote:
On Tue, 2005-03-01 at 07:53 -0800, Rahul Sundaram wrote:
Hi
kedit and gedit could be moved to Extras without much pain.
bad idea
what GUI text editors are KDE and GNOME users supposed to use?.
Either pull one of those in Extras, .. or learn to launch a terminal and start an ASCII-editor :-)
.. may-be then they finally realize they don't need one of these GUI- editors ;-)
In emergency situations they will have to use them anyway ... Oh, wait, I forgot, these users will reinstall everything, should the X-server come up, or something else prevent them from logging in "graphically".
Ralf
This is sarcasm correct? There will be a *simple gui text editor* in fc4 right? -mf
In emergency situations they will have to use them anyway ... Oh, wait, I forgot, these users will reinstall everything, should the X-server come up, or something else prevent them from logging in "graphically".
Ralf
This is sarcasm correct? There will be a *simple gui text editor* in fc4 right?
yes, There will be a simple gui text editor. Ralf has no more control over core than you or I.
-sv
Le samedi 26 février 2005 à 12:24 -0500, Eric Warnke a écrit :
*dovecot/cryus - IMAP server cyrus does seem more like a specialty package when compared to the simplcity and utility of dovecot.*
Therefore dovecot and cyrus do not really overlap. Unlike all the console web browsers for example they target widely different publics.
(cyrus could certainly be in extras but I believe it needs to be maintained for RHEL and it seems all the linux "exchage killers" rely on it one way or the other. Plus I may be wrong but cyrus auth libs are used by other packages)
Regards,
On Sat, 26 Feb 2005 19:33:23 +0100, Nicolas Mailhot Nicolas.Mailhot@laposte.net wrote:
(cyrus could certainly be in extras but I believe it needs to be maintained for RHEL and it seems all the linux "exchage killers" rely on it one way or the other. Plus I may be wrong but cyrus auth libs are used by other packages)
cyrus-sasl is a requirement for some important items like openldap and sendmail and even mutt.
-jef
Since this is the second time this has come up...
Is being part of RHEL reason enough to keep things in core? If that is the case I will exclude from my list all packages that exist in RHEL. Personally I don't think that should be the goal here.
If you want RHEL compatibility then get a RHEL knockoff.
Cheers Eric
Michael Schwendt wrote:
On Sat, 26 Feb 2005 12:24:18 -0500, Eric Warnke wrote:
Possible without objections mc - Is this really a core util? would it be better served in extras?
Considering that it was re-added to RHEL 4, yes.
Once upon a time, Eric Warnke eric@snowmoon.com said:
Is being part of RHEL reason enough to keep things in core? If that is the case I will exclude from my list all packages that exist in RHEL. Personally I don't think that should be the goal here.
In the Objectives of Fedora Core:
13. Form the basis of Red Hat's commercially supported operating system products.
http://fedora.redhat.com/about/objectives.html
On Sat, 26 Feb 2005, Chris Adams wrote:
Once upon a time, Eric Warnke eric@snowmoon.com said:
Is being part of RHEL reason enough to keep things in core? If that is the case I will exclude from my list all packages that exist in RHEL. Personally I don't think that should be the goal here.
In the Objectives of Fedora Core:
- Form the basis of Red Hat's commercially supported operating system products.
Don't worry about whether the packages are in RHEL - we'll sort out that mess when we come to it. ;-)
-- Elliot
On Sat, 26 Feb 2005 13:52:45 -0500, Eric Warnke eric@snowmoon.com wrote:
Since this is the second time this has come up...
Is being part of RHEL reason enough to keep things in core? If that is the case I will exclude from my list all packages that exist in RHEL. Personally I don't think that should be the goal here.
There is no clear answer to this yet. The issue is complicated however by the fact that Extras buildsystem is seperate from the Red Hat internal buildsystem Core and RHEL both currently use. I'm sure the buildsystem constraints factor into how Red Hat decides where to keep RHEL relevant components under their control.
-jef
Is it that difficult for RH to maintain contol, but be copied to extras for building in Fedora Extras? If this is not already a thread internal to RH it should be. What is the real and expected deliniation between FC, FE, RHEL, and RH as a company and the maintainers and community at large? I understand there are real business issues that forced the creation of FE, but now the continued push for more community involvment necessatated by package maintanince and thereby extending FE into FC's old territory... what's the deal?
I don't expect anyone can answer the question right now, but I think we at least deserve an answer at some point in the near future.
Cheers, Eric
Jeff Spaleta wrote:
On Sat, 26 Feb 2005 13:52:45 -0500, Eric Warnke eric@snowmoon.com wrote:
Since this is the second time this has come up...
Is being part of RHEL reason enough to keep things in core? If that is the case I will exclude from my list all packages that exist in RHEL. Personally I don't think that should be the goal here.
There is no clear answer to this yet. The issue is complicated however by the fact that Extras buildsystem is seperate from the Red Hat internal buildsystem Core and RHEL both currently use. I'm sure the buildsystem constraints factor into how Red Hat decides where to keep RHEL relevant components under their control.
-jef
On Saturday 26 February 2005 15:40, Eric Warnke wrote:
Is it that difficult for RH to maintain contol, but be copied to extras for building in Fedora Extras? If this is not already a thread internal to RH it should be. What is the real and expected deliniation between FC, FE, RHEL, and RH as a company and the maintainers and community at large? I understand there are real business issues that forced the creation of FE, but now the continued push for more community involvment necessatated by package maintanince and thereby extending FE into FC's old territory... what's the deal?
When Red Hat stopped doing Red Hat Linux and started up Fedora Core, my interpretation of the objectives was that Fedora Core would be testbed for RHEL and that packages which are part of RHEL would (in almost all cases) would also be in Fedora Core. However, there will likely be packages in Fedora Core which are not in RHEL.
Now when there is some kind of transition with packages providing function (e.g., LPNG and cups), a package may be dropped from a current Fedora Core while still in the current RHEL ... this would be a "test" to see if the package could be dropped. A current example might be keeping emacs while moving xemacs to Fedora Extras. I assume that this is a test to see if the same can be done with RHEL (remove xemacs from the basic RHEL).
One question that occurs to me is whether there will be something like a RHEL Extras to add not-so-widely-used packages to the commercial RHEL distribution.
Once upon a time, Eric Warnke eric@snowmoon.com said:
lynx/w3m+w3m-el/elinks - 1 objection about scripts using lynx... ether those scripts are not part of core or they are not marked correctly. If you can surf the web with either, you can download them from extras. If either has a dependancy in core the .src.rpm needs to be corrected. Personally I think lynx should go to extras.
At one time, lynx was the only one of those that could do SSL, basic authentication, etc. (I don't know the current state of all of them because I use lynx). I think it may still be the only one that verifies SSL certificates.
An example of a script that uses lynx is the Apache apachectl script. IIRC the perl CPAN module can also use it when libwww-perl is not available. Since lynx was (and may still be) the widest-spread text mode browser, many third party and home-grown scripts use it. I haven't seen scripts that come out-of-the box that use any of the others; that would be a reason to keep lynx over the others.
usermode/utempter - overlaps with sudo
No it doesn't.
nut - nice package, but is it really core materal?
It should be. Every UPS at Best Buy and even Wal-Mart has shutdown software for Windows, and nut is the tool to use for Linux. It is useful for both workstations and servers.
dosfttools - looks like mtools superceeds this package.
Actually mtools predates dosfstools (I used mtools on Suns at least 12-14 years ago IIRC). However, they don't overlap entirely. Mtools is designed mainly to operate on floppies and wants to do things in terms of drive letters (that have to be configured). Dosfstools has VFAT mkfs and fsck utils that work just like other Unix filesystem mkfs/fsck (and can handle more mkfs options). I don't think mtools includes an fsck equivalent.
strace - looks like ltrace provides same functionality
Not at all. Strace looks at system calls and ltrace looks library calls (hence the "s" vs. the "l").
iptstate - package getting stale
In what way? Is there duplicated functionality, or is it in way out of date? It performs its function (quite well), is up to date with respect to the interfaces required, and is the only tool for the job I believe. There are numerous packages that don't get regular updates because they just work and the requirements don't change.
I built some walls today, but I didn't go buy a new hammer just because mine is old (although I did look at some new ones at the hardware store!).
lftp - useful ftp client ( ftp, ncftp ) D:0
Lftp is much more useful than ncftp (and lftp is in the default install where ncftp is not). Drop ncftp instead.
a2ps - text to postscript tool required by xfprint
No idea how easy a2ps may be to remove, but GNU enscript is another flexible text to Postscript tool that is also included (don't know if the functionality is the same though).
star - tar with acl support.
Yes, and AFAIK there is no included alternative to backing up ACLs.
pinfo - another text info file browser - do we need two?
The info interface may be great if you are an emacs user, but it is not for the rest of us. Pinfo is far superior for normal people.
freeradius - complex package d:0
So are OpenOffice.org, xorg-x11, kernel, etc. That is no reason to remove something. It is also a useful package for servers.
mc - Is this really a core util? would it be better served in extras?
There is no other text-mode file manager (except for a basic bit in lynx IIRC).
On Sat, 26 Feb 2005 14:44:48 -0600, "CA" == Chris Adams cmadams@hiwaay.net wrote:
CA> Once upon a time, Eric Warnke eric@snowmoon.com said:
lynx/w3m+w3m-el/elinks - 1 objection about scripts using lynx... ether those scripts are not part of core or they are not marked correctly. If you can surf the web with either, you can download them from extras. If either has a dependancy in core the .src.rpm needs to be corrected. Personally I think lynx should go to extras.
CA> At one time, lynx was the only one of those that could do SSL, basic CA> authentication, etc. (I don't know the current state of all of them CA> because I use lynx). I think it may still be the only one that verifies CA> SSL certificates.
w3m can do it as well, though.
-- Akira TAGOH
At this point I think I have weeded out all of the packages that should not be moved and solicited enough feedback to give put forward a reasonable set of packages to be moved from core to extras.
This is the last posting to this list. Please forward additional comments off-list and I will pass the whole parcel along in a day or two.
I do believe in a slimed down core so that we all can have a stronger and more efficient base of software to work from. To divert energy into packages that duplicate effort seems waistful and counter productive. To that end I submit to the community the list of packages that I think should migrate to extras and be picked up by the community or be dropped.
I am also willing to pick up some of these packages in extras based if they are used in my environment and current maintainers want to give them up.
*Recomendation for depreciation*
fsh - fast shell, features being absorbed into OpenSSH ( Depreciate in anticipation of OpenSSH functionality )
*Ojections, let technical team make final call.*
mc - Is this really a core util? would it be better served in extras? several objections as the only text mode file manager. I'm on the fence on this one.
freeglut - libtiff dependancy - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149784
dovecot/cryus - IMAP server cyrus does seem more like a specialty package when compared to the simplcity and utility of dovecot. OTOH cyrus is maintained for RHEL and other packages depends on cyrus-sasl. The community definatly appears to favor keeping dovecot and letting cyrus be religated to extras.
lynx/w3m+w3m-el/elinks - 1 objection about scripts using lynx... ether those scripts are not part of core or they are not marked correctly. If you can surf the web with either, you can download them from extras. If either has a dependancy in core the .src.rpm needs to be corrected. Personally I think lynx and w3m should go to extras.
SDL - Few things depend on this. 1 objection. Would be nice to have in core, but is really not a core function since nothing in core depends on it. Anything that is going to require it can pull it down from extras. + kdeaddons - small add on packages. not 100% necessary. + gstreamer-plugins + theora-tools ! *gnomemeeting* - It is possible to compile without SDL support, I will test that change ans see what aspects of the program it affects.
nut - nice package, but is it really core materal? 1 objection used on server. Is server use enough to keep it in core?
talk - protocol is getting old with IM - 3 objections... do people still use this. Last time I saw this in active use was a decade ago. Unlike other mature tools nothing really depends on talk. I think this is in the same category as telnetd, it's just not in wide enough use to justify keeping it in core.
*Recommend eviction from core*
ncftp - duplicate funcationality ( ftp, lftp ) nobody appeard to have any love lost if this moves to extras w3m/w3m-el - another text pager/web browser tora - packaged without oracle plugin and does not appear to work out of the box with MySQL or postgress. tix - Tcl/Tk extansion ( only id tkinter can go as well ) routed - appears to be superceeded by quagga qmkbootdisk - graphical boot disk creation utiltiy - stale ots - was used as part of abiword, but abiword has been religated to extras. This one is a no brainer nss_db - partly broken. Most usefulness gone now that nscd is standard ( I will personally manage since I wrote the fix ) mew - emailing in emacs dmalloc, valgrind - electricfence appears to be more compatible and better developed. giftrans - netpbm tools can do the same iptstate - package getting stale jed - another text mode editor joe - yet another text editor ( nano / emacs / vi ) nedit - another x text editor Canna - Superceeded by IIMF - nothing depends ! 10MB MagicPoint - Duplicated functionality already in other packages OO.o a2ps - text to postscript tool required by xfprint ( xfprint already in extras ) no brainer awesfx - OLD ( 2000 ) D:0 cdecl - C/C++ to English conversion D:0 apel - extras for emacs + ddskk - extra input methods for emacs + flim - message encoding emacs + wl - imap/pop/nntp reader arptables_jf - specialized filtering of arp D:0 cscope - c code browser - duplicate effort D:0 cdlabelgen - does anyone use? D:0 autorun - functionality in most desktops already d:0 ftpcopy - utility D:0. I have never used it do we need in core g-wrap - Another wrapper for a development utility d:0
Cheers,
Le dimanche 27 février 2005 à 00:09 -0500, Eric Warnke a écrit :
nut - nice package, but is it really core materal? 1 objection used on server. Is server use enough to keep it in core?
You know UPSes are not only unsed for servers. They are for example quite common in HomeCinema setups where you absolutely do not want a power failure to shorten dramatically the life of your equipment by shutting down your projector before it has the chance to cool down its lamp by running its fans at max settings for a few minutes (the lamp is the single most expensive and delicate component of a video projector)
Regards,
BTW pan was moved to extras but I don't remember what the official replacement was supposed to be. Objections were raised by Alan Cox among others.
Regards,
Dnia 27-02-2005, nie o godzinie 11:09 +0100, Nicolas Mailhot napisał(a):
BTW pan was moved to extras but I don't remember what the official replacement was supposed to be.
I'd say Evo, but I don't know what's the official one really is.
Lam
On Sun, Feb 27, 2005 at 12:09:44AM -0500, Eric Warnke wrote:
dmalloc, valgrind - electricfence appears to be more compatible and better developed.
Please don't mention valgrind in the list of packages you want to remove. Valgrind is a real necessity in finding memory allocation bugs, but so is ElectricFence, malloc checking in glibc and mudflap.
dmalloc I have no objection to, but valgrind is really going to stay.
Jakub
On Sun, Feb 27, 2005 at 12:09:44AM -0500, Eric Warnke wrote:
dovecot/cryus - IMAP server cyrus does seem more like a specialty package when compared to the simplcity and utility of dovecot. OTOH cyrus is maintained for RHEL and other packages depends on cyrus-sasl. The community definatly appears to favor keeping dovecot and letting cyrus be religated to extras.
If cyrus-sasl can't be separated easily from cyrus IMAP, then it needs to stay. sasl is an authentication library that is needed by many components of LDAP/Kerberos authentication strategies.
lynx/w3m+w3m-el/elinks - 1 objection about scripts using lynx... ether those scripts are not part of core or they are not marked correctly. If you can surf the web with either, you can download them from extras. If either has a dependancy in core the .src.rpm needs to be corrected. Personally I think lynx and w3m should go to extras.
lynx should stay if it is the only one that does Basic Auth and SSL well. In fact, I change my stance here and say that lynx should stay based on the argument that scripts, libraries, and applications use it. It existed for so long before the other text browsers, that it has become the defacto standard way to "bootstrap" things from the net.
SDL - Few things depend on this. 1 objection. Would be nice to have in core, but is really not a core function since nothing in core depends on it. Anything that is going to require it can pull it down from extras.
- kdeaddons - small add on packages. not 100% necessary.
- gstreamer-plugins
- theora-tools
theora-tools should stay. We need to have an unencumbered suite of multimedia tools in Core, if for no other reason than to encourage widespread adoption of open formats over closed ones.
nut - nice package, but is it really core materal? 1 objection used on server. Is server use enough to keep it in core?
Yes. Core is not just a desktop distribution. nut should stay.
talk - protocol is getting old with IM - 3 objections... do people still use this. Last time I saw this in active use was a decade ago. Unlike other mature tools nothing really depends on talk. I think this is in the same category as telnetd, it's just not in wide enough use to justify keeping it in core.
We're talking (no pun intended) about 22k installed (50k source) here... With 3 objections to it, why worry about it so much? Just keep it...
*Recommend eviction from core* routed - appears to be superceeded by quagga
routed is a very simple RIP protocol daemon sometimes used by non-routers in listen-only mode (-q) to learn the available routes on the network (default route, other routes). It is this aspect of routed that maybe should keep it in Core. Source 43 KB. Installed 40 KB. I say keep it.
quagga is really a much larger package that supports many more routing protocols than just RIP, and is intended for large routers, route servers, etc. not network clients, nor your simple home router. It is much more complex, and as such doesn't really fill the need that routed fills. Source 2 MB. Installed 4+ MB. If either package goes, this one should. This seems like a perfect candidate for Extras, given its small target audience.
dmalloc, valgrind - electricfence appears to be more compatible and better developed.
I thought valgrind was supposedly so much better than the others? I remember at one time it had been encumbered by patents or something, and as such it couldn't be included at the time. Now that it is in there, should we really remove it again? I have no strong opinion on this one, just asking... Extras could certainly take this one if desired.
iptstate - package getting stale
Stale? It was initially packaged in Jan 2004, and recently updated in Feb 2005. Again, this is only 17 KB source, 39 KB installed. I say keep it. It sounds very useful.
a2ps - text to postscript tool required by xfprint ( xfprint already in extras ) no brainer
Agreed. As long as we keep enscript.
please do not axe dovecot. it's the first imap server that runs out of the box without major trouble.
On Sun, 27 Feb 2005 12:07:27 -0500, Chuck R. Anderson cra@wpi.edu wrote:
On Sun, Feb 27, 2005 at 12:09:44AM -0500, Eric Warnke wrote:
dovecot/cryus - IMAP server cyrus does seem more like a specialty package when compared to the simplcity and utility of dovecot. OTOH cyrus is maintained for RHEL and other packages depends on cyrus-sasl. The community definatly appears to favor keeping dovecot and letting cyrus be religated to extras.
If cyrus-sasl can't be separated easily from cyrus IMAP, then it needs to stay. sasl is an authentication library that is needed by many components of LDAP/Kerberos authentication strategies.
On 00:09 27 Feb 2005, Eric Warnke eric@snowmoon.com wrote: | w3m/w3m-el - another text pager/web browser
Part of the standard recipe for rendering HTML in mutt (and probably other text mode mail readers). Given that you advocate punting lynx too, how do you suggest text mode users render HTML for humans?
| nss_db - partly broken. Most usefulness gone now that nscd is standard (
It would be good for nscd to have a useful manual page. Its OPTIONS section says:
--help will give you a list with all options and what they do.
| a2ps - text to postscript tool required by xfprint ( xfprint already in | extras ) no brainer
Got another text->ps in core please? Some tools are used on their own!
Cameron Simpson writes:
| w3m/w3m-el - another text pager/web browser
Part of the standard recipe for rendering HTML in mutt (and probably other text mode mail readers). Given that you advocate punting lynx too, how do you suggest text mode users render HTML for humans?
There are at least three text browsers in FC. All that's being proposed is removing one or two. A means of rendering HTML for text mode users will remain. Exactly which means of doing so it what's being discussed (FWIW, I use both lynx and links on a regular basis, but could happily lose w3m).
Tet
On Sat, 2005-02-26 at 12:24 -0500, Eric Warnke wrote:
Please post feedback. All objections noted.
Xaw3d - required by emacs and emacs is being kept
libXaw should not be removed. It is one fundamental libs in X11, many (older, however still useful) applications are based on.
Ojections, but I still believe could be moved.
*freeglut - library with no dependancy in core. libtiff requirement can be corrected. I am working on a patch or updated spec file.*
Basis for many GL applications. Should be shipped in parallel to libGL/Mesa/X11 and should be regarded integral part of X11.
joe - yet another text editor ( nano / pico / emacs / ed / vi )
Not just "yet another text editor". It's the only Wordstar compatible ASCI-editor in Fedora (WordStar has dominated the editor market in the late 1980/90's, generations of users have grown up with it.) Removing it from FC means a severe loss of functionally to this generation of users.
Ralf
On Sun, 27 Feb 2005 12:23:57 +0100, Ralf Corsepius rc040203@freenet.de wrote:
joe - yet another text editor ( nano / pico / emacs / ed / vi )
Not just "yet another text editor". It's the only Wordstar compatible ASCI-editor in Fedora (WordStar has dominated the editor market in the late 1980/90's, generations of users have grown up with it.) Removing it from FC means a severe loss of functionally to this generation of users.
I agree wholeheartedly. It just wouldn't be the same without both of these guys. :)
Cheers,
On Sat, 26 Feb 2005 12:24:18 -0500, "EW" == Eric Warnke eric@snowmoon.com wrote:
EW> h2ps - should let people that use multinational tools decide which one EW> go and which ones stay
Right now is there any good candidate tool to replace it? otherwise it's required to do print the Korean text out.
EW> lynx/w3m+w3m-el/elinks - 1 objection about scripts using lynx... ether EW> those scripts are not part of core or they are not marked correctly. If EW> you can surf the web with either, you can download them from extras. If EW> either has a dependancy in core the .src.rpm needs to be corrected. EW> Personally I think lynx should go to extras.
lynx/elinks has a problem to look at each native encodings which almost website uses since we are using UTF-8 locale. w3m only can takes care of it. for m17n, we should keep w3m in FC for the usability.
EW> *New additions to the likley list* EW> w3m/w3m-el - another text pager/web browser
w3m-el might be moved into FE, but not w3m as the above reason.
EW> Canna - Superceeded by IIMF - nothing depends ! 10MB
Don't move. IIIMF is just a framework, and Canna is used as the backend of Japanese.
EW> *VFlib2 - Required by MajicPoint and ghostscript - only if we can break EW> the ghostscript compatibility
VFlib2 is required for the correct vertical writing printing on ghostscript. don't break it without any fixes.
Regards, -- Akira TAGOH
On Sat, 2005-02-26 at 12:24 -0500, Eric Warnke wrote:
lynx/w3m+w3m-el/elinks
I think we should have a text-mode browser in core, personaly I vote for elinks. The only thing I missed with elinks was the -dump feature that was available only in lynx. The recent elinks has this feature so I think elinks is the best from these now.
usermode/utempter - overlaps with sudo
Nope, usermode contains not only authentication helpers, but also usermount and other things that are of course missing in the other mentioned packages. Many programs are dependent on userhelper now so it's quite impossible to replace it by anything else at the moment.
nedit - another x text editor
No objections against dropping this from core.
mc - Is this really a core util? would it be better served in extras?
This is very useful thing that should be in core. I don't see any substitute for it in field of text-mode file managers and it has some unique features such as rpm vfs that helps many people.
Jindrich
On Sat, 26 Feb 2005 10:17:12 -0500, Eric Warnke eric@snowmoon.com wrote:
Jeff,
This was meant to spark discussion... not to be the end all be all.
Jeff Spaleta wrote:
how are you checking for deps? the libtiff deps isnt somthing obscure.. its required by gtk2. I just want to make sure you aren't wasting your time using a depcheck method thats going to be highly unreliable. Are you looking at the deps in fc3 or in rawhide? I'm not sure looking at the dep chains in fc3 gives an accurate picture for the sake of this discussion.
I could not find a rpmdb for rawhide. If you wish to send me one I would be more than happy to use it. I have been using rpm -w --whatrequires under the full fc3 rpmdb.
dasher - obscure alternate input method ! 10MB
uhm... thats almost an offensive comment... a11y elements are very important... just be glad you don't need them.
If it is used by kde or gnomes accessability feature and used by someone ( anyone ) I will remove it from consiteration.
Your other objections are noted, but I stand by freeradius as a specialty package probably better served in extras.
freeradius is used a lot on mixed windows/unix enviroments. You might as well kill kerberos if you kill that one.
On Thu, 03 Mar 2005 19:47:53 -0500, seth vidal skvidal@phy.duke.edu wrote:
freeradius is used a lot on mixed windows/unix enviroments. You might as well kill kerberos if you kill that one.
to be fair, it's not killing, it's just moving.
and to my knowledge nothing links to freeradius like things link to krb5.
That is true. Sorry.. its been a crappy set of weeks in .gov land and should give a bit more lag time before posting. [Or as Tim Powers used to say.. if Smooge says something sort of angry like he will post a retraction later :)]
On Saturday 26 February 2005 15:24, Eric Warnke wrote:
dovecot - IPAP server - 2 objections, but if you can server to the internet, you can download it from extras. Ether this or cyrus should be cut.
I second removing cyrus from Core as it is really special purpose.
On Feb 26, 2005, Ronny Buchmann ronny-vlug@vlugnet.org wrote:
On Saturday 26 February 2005 15:24, Eric Warnke wrote:
dovecot - IPAP server - 2 objections, but if you can server to the internet, you can download it from extras. Ether this or cyrus should be cut.
I second removing cyrus from Core as it is really special purpose.
+1
dovecot works out of the box. cyrus is useless out of the box, and hardly compatible with anything else in the distro.
BTW in a related topic if the arts part could be spun out of gstreamer-plugins this system could run without qt installed.
It'd be easier to drop out suff later if it's not deeply linked like this
Regards,
On Sat, 2005-02-26 at 19:29 +0100, Nicolas Mailhot wrote:
BTW in a related topic if the arts part could be spun out of gstreamer-plugins this system could run without qt installed.
My hope is that we can go with ALSA sound mixing on by default and simply drop the arts gstreamer plugin, since AFAIK it's only used by people using arts for sound mixing and who want gstreamer apps to output to arts.
On 02/27/2005 08:42:53 AM, Colin Walters wrote:
On Sat, 2005-02-26 at 19:29 +0100, Nicolas Mailhot wrote:
BTW in a related topic if the arts part could be spun out of gstreamer-plugins this system could run without qt installed.
My hope is that we can go with ALSA sound mixing on by default and simply drop the arts gstreamer plugin, since AFAIK it's only used by people using arts for sound mixing and who want gstreamer apps to output to arts.
No objections from me - gstreamer-plugins is the only reasin qt is on my system.
BTW in a related topic if the arts part could be spun out of gstreamer-plugins this system could run without qt installed.
My hope is that we can go with ALSA sound mixing on by default and simply drop the arts gstreamer plugin, since AFAIK it's only used by people using arts for sound mixing and who want gstreamer apps to output to arts.
No objections from me - gstreamer-plugins is the only reasin qt is on my system.
See also https://bugzilla.redhat.com/beta/show_bug.cgi?id=108463.
Dnia 26-02-2005, sob o godzinie 09:24 -0500, Eric Warnke napisał(a):
jed - another text mode editor joe - yet another text editor ( nano / pico / emacs / ed / vi ) lftp - useful ftp client ( ftp, ncftp ) D:0
Just like desktop environments, it's really hard to say one editor can substitute another. Unlike DE-s, text editors are rather small (I use joe - 200 KiB RPM file, even nano having 1% of joe features is bigger) and removing them doesn't give this much benefit (meaning saved space) as removing f.e. KDE (since GNOME is the default, why haven't you list KDE? :)).
I say let's move vi to Extras - an editor which can't be left with ^C deserves this! :)
Is pico part of Rawhide now? I thought its licence is the same as pine's and can't be included, besides, you're using FC3 rpmdb and pico can't be found there.
Can ed be thought of as a replacement for any full-screen text editor? :)
Of course I won't go mad if joe is going to be moved to Extras, downloading 200 KiB will take only 20 seconds on my link, so go ahead, make my life harder and not gain anything for the Core :)
Lam
On Sun, Feb 27, 2005 at 10:38:35AM +0100, Leszek Matok wrote:
I say let's move vi to Extras - an editor which can't be left with ^C deserves this! :)
I don't think we should remove vi--it is the basic, traditional *nix editor. Note that I'm not a vi zealot--I actually use all three of vi, emacs, and nano for various different tasks...
Is pico part of Rawhide now? I thought its licence is the same as pine's and can't be included, besides, you're using FC3 rpmdb and pico can't be found there.
No, nano replaced pico. cone (in Extras) is intended to replace pine. I don't think nano should be removed from Core. In fact, when cone is ready, I think it should be brought into Core.
On Sun, 2005-02-27 at 12:17 -0500, Chuck R. Anderson wrote:
No, nano replaced pico. cone (in Extras) is intended to replace pine. I don't think nano should be removed from Core. In fact, when cone is ready, I think it should be brought into Core.
Nano could really do with UTF-8 support. I'm very tempted to ship a CVS snapshot for that reason, although that's generally not a good thing to do.
Cone still lacks the capability to get at IMAP servers by rsh/ssh, doesn't it?
On Sun, Feb 27, 2005 at 05:21:41PM +0000, David Woodhouse wrote:
Nano could really do with UTF-8 support. I'm very tempted to ship a CVS snapshot for that reason, although that's generally not a good thing to do.
Go for it. We should put the CVS snapshot into Rawhide/FC4t1 and see how it goes. It can be downgraded later if it doesn't go so well.
On 02/26/2005 06:24:40 AM, Eric Warnke wrote:
lftp - useful ftp client ( ftp, ncftp ) D:0
Absolutely the best cli ftp client I have ever used. Any *other* ftp clients are redundant :p
Yes, there's curl and wget etc. which can download, yes - there's the standard ftp command, yes - lftp could be fetched from extras, but I think it should stay - it's not very big, and I bet it is heavily used.
I think the idea behind moving stuff to Extras should not be to move every duplicate package - if masses of people are just going to yum install it, and it is small, it might as well be on the install CD.
AbiWord/Gnumeric being large packages that aren't used by a lot of people are good examples.
lftp (under 1 MB) and lynx (under 2MB) are small packages that are used by a fair number of people - they should thus not be moved.
On Sat, Feb 26, 2005 at 09:24:40AM -0500, Eric Warnke wrote:
dovecot - IPAP server - 2 objections, but if you can server to the internet, you can download it from extras. Ether this or cyrus should be cut.
Cyrus should go then. Dovecot works for any user but Cyrus requires an expert to set up its way of doing things.
*lynx/elinks - 1 objection about scripts using lynx... ether those scripts are not part of core or they are not marked correctly. If you can surf the web with either, you can download them from extras. If either has a dependancy in core the .src.rpm needs to be corrected. Personally I think lynx should go to extras.*
Lynx is essential for blind users, elinks could go.
*New additions to the likley list* dmalloc, valgrind - electricence appears to be more compatible and better developed. freeglut - library with no dependancy in core
Freeglut is basically expected to be part of an OS with OpenGL
giftrans - netpbm tools can do the same
netpbm tools are garbage, lose netpbm instead. netpbm security is abysmal and functionality iffy.
iptstate - package getting stale jed - another text mode editor joe - yet another text editor ( nano / pico / emacs / ed / vi ) lftp - useful ftp client ( ftp, ncftp ) D:0
As a heavyweight joe user I still agree it should be extras
MAKEDEV - Superceeded by udev ?
Not always and tiny
*VFlib2 - Required by MajicPoint and ghostscript - only if we can break the ghostscript compatibility
- MagicPoint - Duplicated functionality already in other packages
Not duplicated at all. May be appropriate for extras for other reasons but there is no duplication between mgp and openoffice because openoffice can't do most of what mgp can do and vice versa
awesfx - OLD ( 2000 ) D:0
Needed for SB64 still
cdecl - C/C++ to English conversion D:0
Tiny
autorun - functionality in most desktops already d:0
Should go - its dangerous anyway
ftpcopy - utility D:0. I have never used it, do we need in core
ssh + rsync nowdays
Alan
Hi
autorun - functionality in most desktops already
d:0
Should go - its dangerous anyway
Alan, can you please clarify that statement. its redundant obviously but why is it dangerous?
===== Regards Rahul Sundaram
__________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail
On Tue, Mar 01, 2005 at 06:33:51AM -0800, Rahul Sundaram wrote:
Alan, can you please clarify that statement. its redundant obviously but why is it dangerous?
The various "automatically run" tools get dangerous because they provide paths for exploits. There is the obvious binary approach (eg a Windows CD that has autorun of format/u c: and is labelled PORN) but there are more subtle tricks too - CD's with movies on them that exploit older video players, or with html and images that exploited linux/windows image viewer holes.
It's a trust thing.
Alan
On Tue, 2005-03-01 at 09:29 -0500, Alan Cox wrote:
On Sat, Feb 26, 2005 at 09:24:40AM -0500, Eric Warnke wrote:
dovecot - IPAP server - 2 objections, but if you can server to the internet, you can download it from extras. Ether this or cyrus should be cut.
Cyrus should go then. Dovecot works for any user but Cyrus requires an expert to set up its way of doing things.
cyrus works great for large number of users/domains, with authentication from databases instead of system users. Please keep both (I never used dovecot, but it looks to work out-of-the-box compared to cyrus). Btw, cyrus default config should work with system users in the same way live dovecot?
awesfx - OLD ( 2000 ) D:0
Needed for SB64 still
But it still (fc2...) aren't automatically setup with some free soundfont set. Somhow i just got stuck with timitity - it can use *much* larger midi patches than i can load into the RAM of my SBAWE64 :)
So either fix so that some patch is loaded by default, setup timidity with some resonable patchset (CCRMA?) or drop it altogether and let users wanting to play a midi file suffer.
Kyrre
On Sat, Feb 26, 2005 at 08:38:51AM -0500, Eric Warnke wrote:
dovecot - IPAP server - 2 objections, but if you can server to the internet, you can download it from extras. Ether this or cyrus should be cut.
cyrus, then. Dovecot is more general-purpose.
Eric, thanks for taking on this task! Just a couple of comments
On Sat, 26 Feb 2005, Eric Warnke wrote:
dovecot - IPAP server - 2 objections, but if you can server to the internet, you can download it from extras. Ether this or cyrus should be cut.
cyrus is not as widely useful, so it probably would be moved to Extras if anything.
lynx/elinks - 1 objection about scripts using lynx... ether those scripts are not part of core or they are not marked correctly. If you can surf the web with either, you can download them from extras. If either has a dependancy in core the .src.rpm needs to be corrected.
A while back I tried to work out the whole "text mode browser" confusion. There is also w3m in the mix. Each of them has unique attributes for particular users (blind users, CJK users, etc.) Someone such as yourself needs to find out all the details, pick the best one or two for the overall Fedora audience, and move the other(s) to Extras.
Best, -- Elliot
On Mon, 28 Feb 2005 11:51:06 -0500 (EST), Elliot Lee sopwith@redhat.com wrote:
A while back I tried to work out the whole "text mode browser" confusion. There is also w3m in the mix. Each of them has unique attributes for particular users (blind users, CJK users, etc.) Someone such as yourself needs to find out all the details, pick the best one or two for the overall Fedora audience, and move the other(s) to Extras.
is there a reasonable good checklist of 'details' people are suppose to be looking for? Its very easy to forget about CJK users or the like if you personally never have to deal with the tech issues that raises. Last time i checked the closest thing we had was from the desktop group. http://fedora.redhat.com/projects/desktop/defaults.html
Is that enough of a guide for devilish details? accessibility and internationalization are mentioned.. but they have buzzword qualities that might not sink in. Does this need to be re-formulated or at the very least re-packaged and presented somewhere more prominent? It would be nice to have a somewhat standardized set of checkbox items so as each package came up we could weight the pros and cons of competing details that need to be considered.
-jef"valkyrie needs food... badly"spaleta
On Mon, 28 Feb 2005, Jeff Spaleta wrote:
On Mon, 28 Feb 2005 11:51:06 -0500 (EST), Elliot Lee sopwith@redhat.com wrote:
A while back I tried to work out the whole "text mode browser" confusion. There is also w3m in the mix. Each of them has unique attributes for particular users (blind users, CJK users, etc.) Someone such as yourself needs to find out all the details, pick the best one or two for the overall Fedora audience, and move the other(s) to Extras.
is there a reasonable good checklist of 'details' people are suppose to be looking for? Its very easy to forget about CJK users or the like if you personally never have to deal with the tech issues that raises.
Akira is the RH package owner of w3m, and he's well qualified to fill us in on the details because he did that last time I brought the issue up ;-)
-- Elliot
On Mon, 28 Feb 2005 12:23:33 -0500 (EST), "EL" == Elliot Lee sopwith@redhat.com wrote:
EL> On Mon, 28 Feb 2005, Jeff Spaleta wrote:
On Mon, 28 Feb 2005 11:51:06 -0500 (EST), Elliot Lee sopwith@redhat.com wrote:
A while back I tried to work out the whole "text mode browser" confusion. There is also w3m in the mix. Each of them has unique attributes for particular users (blind users, CJK users, etc.) Someone such as yourself needs to find out all the details, pick the best one or two for the overall Fedora audience, and move the other(s) to Extras.
is there a reasonable good checklist of 'details' people are suppose to be looking for? Its very easy to forget about CJK users or the like if you personally never have to deal with the tech issues that raises.
EL> Akira is the RH package owner of w3m, and he's well qualified to fill us EL> in on the details because he did that last time I brought the issue up ;-)
Though I mentioned in the another mail on this thread, the details is simple. even if we use UTF-8 for the default locale, the web page isn't necessarily UTF-8. but both lynx and elinks doesn't take care of it. that's all for the internationalization. We could just ignore it, but it will make it terrible and unusable thing then.
-- Akira TAGOH
Once upon a time, Jeff Spaleta jspaleta@gmail.com said:
-jef"valkyrie needs food... badly"spaleta
Mmm... nethack. I had a good nethack package a while back; sounds like a good excuse to clean it up and learn about maintaining a package in Extras.
On Mon, 2005-02-28 at 12:36 -0600, Chris Adams wrote:
Mmm... nethack. I had a good nethack package a while back; sounds like a good excuse to clean it up and learn about maintaining a package in Extras.
Already there, "yum install nethack-falconseye".
It's the Falcon's eye GUI version of NH; traditional TTY works too: $ NETHACKOPTIONS=windowtype:tty nethack
Once upon a time, Ville Skytt ville.skytta@iki.fi said:
On Mon, 2005-02-28 at 12:36 -0600, Chris Adams wrote:
Mmm... nethack. I had a good nethack package a while back; sounds like a good excuse to clean it up and learn about maintaining a package in Extras.
Already there, "yum install nethack-falconseye".
I saw that, but I want the current "real" nethack. I'll work on it when I get a chance.
On Wed, 2005-03-02 at 10:13 -0600, Chris Adams wrote:
Once upon a time, Ville Skytt ville.skytta@iki.fi said:
On Mon, 2005-02-28 at 12:36 -0600, Chris Adams wrote:
Mmm... nethack. I had a good nethack package a while back; sounds like a good excuse to clean it up and learn about maintaining a package in Extras.
Already there, "yum install nethack-falconseye".
I saw that, but I want the current "real" nethack.
As I tried to say, nethack-falconseye *includes* the "real" nethack (version 3.4.1, so it's lagging slightly behind). See my earlier post how to launch the "real" one instead of the fancy GUI.
I'll work on it when I get a chance.
As long as a reasonably recent version of the traditional one is bundled in nethack-falconseye, I think that time would be better spent on something else. There should be a new NHFE release out soon, which will probably satisfy also the "current" part of what you want above.
devel@lists.stg.fedoraproject.org
-
Akira TAGOH -
Alan Cox -
Alexandre Oliva -
Barry K. Nathan -
Cameron Simpson -
Chris Adams -
Chuck Anderson -
Colin Charles -
Colin Walters -
David Woodhouse -
Demond -
dragoran -
Elliot Lee -
Eric Warnke -
Gene C. -
Harald Hoyer -
Jakub Jelinek -
Jamie Zawinski -
Jef Spaleta -
Jindrich Novy -
Jos Vos -
Karel Zak -
Konstantin Ryabitsev -
Kyrre Ness Sjobak -
Leszek Matok -
Marius Andreiana -
Matthew Miller -
mbneto -
Michael A. Peters -
Michael Favia -
Michael Schwendt -
Miloslav Trmač -
Neal Becker -
Nicolas Mailhot -
Nicolas Mailhot
-
Oleg Goldshmidt -
Paul A Houle -
Pedro Fernandes Macedo -
Peter Vrabec -
Pozsar Balazs -
Rahul Sundaram -
Ralf Corsepius -
Ralf Ertzinger -
Richard June -
Ronny Buchmann -
seth vidal -
Stan Bubrouski -
Stephen John Smoogen -
Tet -
Tomas Mraz -
Ville Skyttä -
W. Michael Petullo