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
--
Eric Warnke Computer Programmer / Systems Analyst
eric(a)snowmoon.com 518-727-1523
GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259
'There is always an easy solution to every human problem -- neat,
plausible, and wrong.' - H.L. Mencken

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(a)pobox.com&gt;

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?".
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>

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?".

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.
--
Michael A. Peters
http://mpeters.us/

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).

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?

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.

> 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
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
"First they ignore you, then they laugh at you, then they fight you,
then you win." -- Mohandas Gandhi

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

On Feb 26, 2005, Eric Warnke <eric(a)snowmoon.com&gt; 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.

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

Alexandre Oliva wrote:
> On Feb 26, 2005, Eric Warnke <eric(a)snowmoon.com&gt; 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?

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
--
Eric Warnke Computer Programmer / Systems Analyst
eric(a)snowmoon.com 518-727-1523
GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259
'There is always an easy solution to every human problem -- neat,
plausible, and wrong.' - H.L. Mencken

"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.
--
Tomas Mraz <tmraz(a)redhat.com&gt;

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

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...

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.

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!

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.

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.

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.

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

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.

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
--
Eric Warnke Computer Programmer / Systems Analyst
eric(a)snowmoon.com 518-727-1523
GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259
'There is always an easy solution to every human problem -- neat,
plausible, and wrong.' - H.L. Mencken

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
--
Eric Warnke Computer Programmer / Systems Analyst
eric(a)snowmoon.com 518-727-1523
GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259
'There is always an easy solution to every human problem -- neat,
plausible, and wrong.' - H.L. Mencken

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.
--
dwmw2

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.

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.

>
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

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.

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.
--
Percussive Maintenance: The fine art of whacking the c**p out of an
electronic device to get it to work again.

Hi.
"Paul A. Houle" <ph18(a)cornell.edu&gt; 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.
--
Michael A. Peters
http://mpeters.us/

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

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(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Once upon a time, Rahul Sundaram
<rahulsundaram(a)yahoo.co.in&gt; 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

Once upon a time, Rahul Sundaram <rahulsundaram(a)yahoo.co.in&gt;
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

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

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 jwz(a)jwz.org http://www.jwz.org/
jwz(a)dnalounge.com http://www.dnalounge.com/http://jwz.livejournal.com/

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.

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).

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,
--
Nicolas Mailhot

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,
--
Eric Warnke Computer Programmer / Systems Analyst
eric(a)snowmoon.com 518-727-1523
GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259
'There is always an easy solution to every human problem -- neat,
plausible, and wrong.' - H.L. Mencken

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.

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 jwz(a)jwz.org http://www.jwz.org/
jwz(a)dnalounge.com http://www.dnalounge.com/http://jwz.livejournal.com/

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....)
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>

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.

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.

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

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, 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?.

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

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

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

*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,
--
Nicolas Mailhot

(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(a)snowmoon.com&gt; 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

Don't worry about whether the packages are in RHEL - we'll sort out that
mess when we come to it. ;-)
-- Elliot

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(a)snowmoon.com&gt; 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?

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.
--
Gene

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.

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.

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!).

> 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,
--
Eric Warnke Computer Programmer / Systems Analyst
eric(a)snowmoon.com 518-727-1523
GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259
'There is always an easy solution to every human problem -- neat,
plausible, and wrong.' - H.L. Mencken

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,
--
Nicolas Mailhot

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

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.

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*
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.

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(a)snowmoon.com&gt; 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 <cs(a)zip.com.au&gt; DoD#743
http://www.cskk.ezoshosting.com/cs/
DON'T DRINK SOAP! DILUTE DILUTE! OK!
- on the label of Dr. Bronner's Castile Soap

| 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

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

> 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,
--
Konstantin Ryabitsev
Zlotniks, INC

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

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.

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.

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
--
Jindrich Novy <jnovy(a)redhat.com&gt;, http://people.redhat.com/jnovy/

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.
--
Stephen J Smoogen.
CSIRT/Linux System Administrator

> 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 :)]
--
Stephen J Smoogen.
CSIRT/Linux System Administrator

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.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}

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,
--
Nicolas Mailhot

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 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.
--
Michael A. Peters
http://mpeters.us/

> 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.

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

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?
--
dwmw2

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.
--
Michael A. Peters
http://mpeters.us/

*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.*

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

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 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?
--
Marius Andreiana
Epon Business Applications
http://www.epon.ro

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

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

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 11:51:06 -0500 (EST), Elliot Lee
<sopwith(a)redhat.com&gt; 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 11:51:06 -0500 (EST), Elliot Lee
<sopwith(a)redhat.com&gt; 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

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.
--
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

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.
--
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Once upon a time, Ville Skytt <ville.skytta(a)iki.fi&gt; 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.

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.