Discussion:
Package pruning for FC4 and beyond
(too old to reply)
Eric Warnke
2005-02-26 05:23:41 UTC
Permalink
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 at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050226/0b7c0783/attachment.bin
Matthew Miller
2005-02-26 06:01:17 UTC
Permalink
Post by Eric Warnke
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.
Post by Eric Warnke
dovecot - IMAP server ( duplication of effort )
Duplication of which effort?
--
Matthew Miller mattdm at mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Barry K. Nathan
2005-02-26 06:26:42 UTC
Permalink
Post by Eric Warnke
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 at pobox.com>
Michael A. Peters
2005-02-26 06:27:52 UTC
Permalink
Post by Eric Warnke
+ emacs ( pick emacs or xemacs and move the other to extras )
keep emacs, move xemacs.
Post by Eric Warnke
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.
--
Michael A. Peters
http://mpeters.us/
Ville Skyttä
2005-02-26 10:26:16 UTC
Permalink
Post by Michael A. Peters
Post by Eric Warnke
+ 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+.
Oleg Goldshmidt
2005-02-26 21:25:04 UTC
Permalink
Post by Ville Skyttä
Post by Michael A. Peters
Post by Eric Warnke
+ 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 ;-).
--
Oleg Goldshmidt | pub at NOSPAM.goldshmidt.org | http://www.goldshmidt.org
Chuck R. Anderson
2005-02-26 17:31:43 UTC
Permalink
Post by Michael A. Peters
Post by Eric Warnke
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).
Matthew Miller
2005-02-26 17:48:03 UTC
Permalink
Post by Chuck R. Anderson
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 at mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Eric Warnke
2005-02-26 17:51:54 UTC
Permalink
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.
Post by Matthew Miller
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?".
--
Eric Warnke Computer Programmer / Systems Analyst
eric at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050226/79da8809/attachment.bin
Michael A. Peters
2005-02-26 19:10:24 UTC
Permalink
Post by Matthew Miller
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/
Karel Zak
2005-02-28 10:39:16 UTC
Permalink
Post by Chuck R. Anderson
Post by Michael A. Peters
Post by Eric Warnke
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
--
Karel Zak <kzak at redhat.com>
Neal Becker
2005-02-28 03:12:15 UTC
Permalink
Post by Michael A. Peters
Post by Eric Warnke
+ emacs ( pick emacs or xemacs and move the other to extras )
keep emacs, move xemacs.
Jamie? How's that sound? :)
Alexandre Oliva
2005-02-26 06:37:59 UTC
Permalink
Post by Eric Warnke
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?
Post by Eric Warnke
epic - duplicate effort
Is there any other text-mode IRC client in Core?
Post by Eric Warnke
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.
Post by Eric Warnke
+ film - message encoding emacs
I suppose you mean flim
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
Colin Charles
2005-02-26 06:53:57 UTC
Permalink
Post by Alexandre Oliva
Post by Eric Warnke
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 at 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
Peter Vrabec
2005-02-28 13:20:10 UTC
Permalink
I don't mind.
Some people in Brno office will invite this replacement.
Post by Colin Charles
Post by Alexandre Oliva
Post by Eric Warnke
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
Neal Becker
2005-02-28 03:11:01 UTC
Permalink
Post by Alexandre Oliva
Post by Eric Warnke
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.
Pedro Fernandes Macedo
2005-02-28 21:07:00 UTC
Permalink
Post by Neal Becker
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
2005-02-28 21:50:16 UTC
Permalink
Post by Neal Becker
Post by Alexandre Oliva
Post by Eric Warnke
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.
Post by Neal Becker
cyrus runs its own database - one reason I don't use it.
Yup, same here.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
Miloslav Trmac
2005-02-26 10:31:41 UTC
Permalink
Post by Eric Warnke
I said it and now I'm doing it.
Thanks! Most of the list looks very reasonable (to me personally, at least).
Post by Eric Warnke
bogl* - kernel 2.2 fb graphics lib D:0
Used in the installer for CJK support in "text mode"
Post by Eric Warnke
doxygen - Sorce code documentation generator D:0
A build dependency of several packages (e.g. kdelibs)
Mirek
Eric Warnke
2005-02-26 13:38:51 UTC
Permalink
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 at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050226/0c4cc2e2/attachment.bin
dragoran
2005-02-26 13:49:08 UTC
Permalink
"SDL* - kdeaddons is the only thing that depends on this"
dropping sdl isn't a good idea because many third party apps require it.
Tomas Mraz
2005-02-28 09:13:34 UTC
Permalink
Post by dragoran
"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 at redhat.com>
Jakub Jelinek
2005-02-26 14:11:19 UTC
Permalink
Post by Eric Warnke
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.
Post by Eric Warnke
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.
Post by Eric Warnke
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
Neal Becker
2005-02-28 03:08:48 UTC
Permalink
Post by Jakub Jelinek
Post by Eric Warnke
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.
Eric Warnke
2005-02-26 14:24:40 UTC
Permalink
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
--
Eric Warnke Computer Programmer / Systems Analyst
eric at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050226/1a2ac405/attachment.bin
Jeff Spaleta
2005-02-26 15:04:29 UTC
Permalink
Post by Eric Warnke
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.
Post by Eric Warnke
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.
Post by Eric Warnke
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
Post by Eric Warnke
ccs - cluster config?
if you don't understand the function perhaps its best not to list as
being removable.
Post by Eric Warnke
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.
Post by Eric Warnke
h2ps - another postscript generator D:0
Are you saying that other cli postscript generators can convert Hangul
and thus overlap in functionality?


-jef
Eric Warnke
2005-02-26 15:17:12 UTC
Permalink
Jeff,

This was meant to spark discussion... not to be the end all be all.
Post by Jeff Spaleta
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.
Post by Jeff Spaleta
Post by Eric Warnke
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
--
Eric Warnke Computer Programmer / Systems Analyst
eric at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050226/0c03d3ba/attachment.bin
Jeff Spaleta
2005-02-26 15:29:53 UTC
Permalink
Post by Eric Warnke
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
Eric Warnke
2005-02-26 17:24:18 UTC
Permalink
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 at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050226/558ae6db/attachment.bin
David Woodhouse
2005-02-26 17:30:17 UTC
Permalink
Post by Eric Warnke
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.
--
dwmw2
Matthew Miller
2005-02-26 17:39:08 UTC
Permalink
Post by Eric Warnke
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.
Post by Eric Warnke
strace - looks like ltrace provides same functionality
nope!
Post by Eric Warnke
pinfo - another text info file browser - do we need two?
the other one really sucks.
Post by Eric Warnke
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.
--
Matthew Miller mattdm at mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Ronny Buchmann
2005-02-26 18:19:46 UTC
Permalink
Post by Matthew Miller
Post by Eric Warnke
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)
--
http://LinuxWiki.org/RonnyBuchmann
Michael A. Peters
2005-02-27 20:25:36 UTC
Permalink
Post by Matthew Miller
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.
--
Michael A. Peters
http://mpeters.us/
Paul A. Houle
2005-02-28 14:01:31 UTC
Permalink
On Sun, 27 Feb 2005 20:25:36 +0000, Michael A. Peters <mpeters at mac.com>
Post by Michael A. Peters
Post by Matthew Miller
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.
Matthew Miller
2005-02-28 14:02:50 UTC
Permalink
Post by Paul A. Houle
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".
--
Matthew Miller mattdm at mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Miloslav Trmac
2005-02-26 17:42:06 UTC
Permalink
Post by Eric Warnke
Please positive feedback only.
<puzzled/> What does this mean?
Post by Eric Warnke
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.
Post by Eric Warnke
nut - nice package, but is it really core materal?
It is one of the basic utilities needed on a "serious" server of any
kind.
Post by Eric Warnke
dosfttools - looks like mtools superceeds this package.
The other way around - mounting is more useful than mcopy.
But _both_ are required for mkbootdisk.
Post by Eric Warnke
MAKEDEV - Superceeded by udev ?
Required by udev, actually.
Post by Eric Warnke
talk - protocol is getting old with IM
UNIX kernel interface is "getting old" too.
Post by Eric Warnke
planner - anther project managment tool
"Another"? What is the alternative?
Post by Eric Warnke
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
Ronny Buchmann
2005-02-26 18:21:55 UTC
Permalink
Post by Miloslav Trmac
Post by Eric Warnke
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.
--
http://LinuxWiki.org/RonnyBuchmann
Jamie Zawinski
2005-02-26 20:19:35 UTC
Permalink
Post by Miloslav Trmac
Post by Eric Warnke
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 jwz at jwz.org http://www.jwz.org/
jwz at dnalounge.com http://www.dnalounge.com/
http://jwz.livejournal.com/
Neal Becker
2005-02-28 03:07:10 UTC
Permalink
Post by Jamie Zawinski
Post by Miloslav Trmac
Post by Eric Warnke
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.
Jeff Spaleta
2005-02-26 18:19:29 UTC
Permalink
Post by Eric Warnke
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.
Post by Eric Warnke
tix - Tcl/Tk extansion
required by tkinter.. as soon as tkinter is dropped this will go.
without complaint i would imagine
Post by Eric Warnke
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.
Post by Eric Warnke
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.
Post by Eric Warnke
lftp - useful ftp client ( ftp, ncftp ) D:0
if yer gonna drop one drop ftp or ncftp instead.. lftp handles ftp and http,
Post by Eric Warnke
MAKEDEV - Superceeded by udev ?
required by udev
Post by Eric Warnke
a2ps - text to postscript tool required by xfprint
xfprint is no longer in the development tree..
Post by Eric Warnke
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.
Post by Eric Warnke
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
seth vidal
2005-02-26 18:25:47 UTC
Permalink
Post by Eric Warnke
jed - another text mode editor
- we already discussed moving this to extras
Post by Eric Warnke
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
Chuck R. Anderson
2005-02-26 18:26:25 UTC
Permalink
Post by seth vidal
vi is not an editor
What is it then?
seth vidal
2005-02-26 22:39:22 UTC
Permalink
Post by Chuck R. Anderson
Post by seth vidal
vi is not an editor
What is it then?
I think it makes music. All I seem to get from it is beeps.

-sv
Michael A. Peters
2005-02-27 20:28:55 UTC
Permalink
Post by seth vidal
I think it makes music. All I seem to get from it is beeps.
LOL! :p
--
Michael A. Peters
http://mpeters.us/
Nicolas Mailhot
2005-02-26 18:33:23 UTC
Permalink
Post by Eric Warnke
*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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050226/cdaf9766/attachment.bin
Jeff Spaleta
2005-02-26 18:38:02 UTC
Permalink
On Sat, 26 Feb 2005 19:33:23 +0100, Nicolas Mailhot
Post by 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
Michael Schwendt
2005-02-26 18:49:11 UTC
Permalink
Post by Eric Warnke
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.
Eric Warnke
2005-02-26 18:52:45 UTC
Permalink
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
Post by Michael Schwendt
Post by Eric Warnke
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.
--
Eric Warnke Computer Programmer / Systems Analyst
eric at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050226/5622228e/attachment.bin
Chris Adams
2005-02-26 20:24:09 UTC
Permalink
Post by Eric Warnke
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
--
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Elliot Lee
2005-02-28 17:03:07 UTC
Permalink
Post by Chris Adams
Post by Eric Warnke
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.
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
Jeff Spaleta
2005-02-26 20:30:10 UTC
Permalink
Post by Eric Warnke
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
Eric Warnke
2005-02-26 20:40:30 UTC
Permalink
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
Post by Jeff Spaleta
Post by Eric Warnke
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
--
Eric Warnke Computer Programmer / Systems Analyst
eric at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050226/024a4758/attachment.bin
Gene C.
2005-02-26 23:34:37 UTC
Permalink
Post by Eric Warnke
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
Chris Adams
2005-02-26 20:44:48 UTC
Permalink
Post by Eric Warnke
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.
Post by Eric Warnke
usermode/utempter - overlaps with sudo
No it doesn't.
Post by Eric Warnke
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.
Post by Eric Warnke
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.
Post by Eric Warnke
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").
Post by Eric Warnke
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!).
Post by Eric Warnke
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.
Post by Eric Warnke
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).
Post by Eric Warnke
star - tar with acl support.
Yes, and AFAIK there is no included alternative to backing up ACLs.
Post by Eric Warnke
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.
Post by Eric Warnke
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.
Post by Eric Warnke
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).
--
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Akira TAGOH
2005-02-28 11:26:01 UTC
Permalink
Post by Eric Warnke
On Sat, 26 Feb 2005 14:44:48 -0600,
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
Eric Warnke
2005-02-27 05:09:44 UTC
Permalink
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 at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050227/0156917b/attachment.bin
Nicolas Mailhot
2005-02-27 10:07:49 UTC
Permalink
Post by Eric Warnke
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050227/64383ca8/attachment.bin
Nicolas Mailhot
2005-02-27 10:09:53 UTC
Permalink
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,
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050227/decd26ea/attachment.bin
Leszek Matok
2005-02-27 10:38:32 UTC
Permalink
Post by Nicolas Mailhot
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
Jakub Jelinek
2005-02-27 11:56:23 UTC
Permalink
Post by Eric Warnke
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
Chuck R. Anderson
2005-02-27 17:07:27 UTC
Permalink
Post by Eric Warnke
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.
Post by Eric Warnke
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.
Post by Eric Warnke
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.
Post by Eric Warnke
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.
Post by Eric Warnke
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...
Post by Eric Warnke
*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.
Post by Eric Warnke
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.
Post by Eric Warnke
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.
Post by Eric Warnke
a2ps - text to postscript tool required by xfprint ( xfprint already in
extras ) no brainer
Agreed. As long as we keep enscript.
mbneto
2005-02-27 22:07:32 UTC
Permalink
please do not axe dovecot. it's the first imap server that runs out of
the box without major trouble.
Post by Chuck R. Anderson
Post by Eric Warnke
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.
Ralf Corsepius
2005-02-27 11:23:57 UTC
Permalink
Post by Eric Warnke
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.
Post by Eric Warnke
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.
Post by Eric Warnke
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
Konstantin Ryabitsev
2005-02-27 21:55:37 UTC
Permalink
Post by Ralf Corsepius
Post by Eric Warnke
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
Akira TAGOH
2005-02-28 11:36:57 UTC
Permalink
On Sat, 26 Feb 2005 12:24:18 -0500,
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
Ronny Buchmann
2005-02-26 15:23:09 UTC
Permalink
Post by Eric Warnke
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.
--
http://LinuxWiki.org/RonnyBuchmann
Alexandre Oliva
2005-02-26 19:21:54 UTC
Permalink
Post by Ronny Buchmann
Post by Eric Warnke
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@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
Nicolas Mailhot
2005-02-26 18:29:04 UTC
Permalink
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050226/69ffc5cc/attachment.bin
Colin Walters
2005-02-27 16:42:53 UTC
Permalink
Post by 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.
Michael A. Peters
2005-02-27 22:34:49 UTC
Permalink
Post by Colin Walters
Post by 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.
No objections from me - gstreamer-plugins is the only reasin qt is on
my system.
--
Michael A. Peters
http://mpeters.us/
W. Michael Petullo
2005-02-28 15:53:42 UTC
Permalink
Post by Michael A. Peters
Post by Colin Walters
Post by 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.
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.
--
Mike

:wq
Leszek Matok
2005-02-27 09:38:35 UTC
Permalink
Post by Eric Warnke
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
Chuck R. Anderson
2005-02-27 17:17:20 UTC
Permalink
Post by Leszek Matok
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...
Post by Leszek Matok
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.
David Woodhouse
2005-02-27 17:21:41 UTC
Permalink
Post by Chuck R. Anderson
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
Chuck R. Anderson
2005-02-27 17:27:51 UTC
Permalink
Post by David Woodhouse
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.
Michael A. Peters
2005-02-27 11:49:29 UTC
Permalink
Post by Eric Warnke
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.
--
Michael A. Peters
http://mpeters.us/
Matthew Miller
2005-02-26 17:25:09 UTC
Permalink
Post by Eric Warnke
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.
--
Matthew Miller mattdm at mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Chuck R. Anderson
2005-02-26 17:35:41 UTC
Permalink
Post by Eric Warnke
doxygen - Sorce code documentation generator D:0 - 1 objecton - I don't
think we necessarly need to keep every build dependancy in core.
Of course we do. Core needs to be able to build itself.
Elliot Lee
2005-02-28 16:51:06 UTC
Permalink
Eric, thanks for taking on this task! Just a couple of comments
Post by Eric Warnke
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.
Post by Eric Warnke
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
Jeff Spaleta
2005-02-28 17:10:44 UTC
Permalink
Post by Elliot Lee
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
Elliot Lee
2005-02-28 17:23:33 UTC
Permalink
Post by Jeff Spaleta
Post by Elliot Lee
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
Chris Adams
2005-02-28 18:36:08 UTC
Permalink
Post by Jeff Spaleta
-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.
--
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Chuck R. Anderson
2005-02-26 18:08:09 UTC
Permalink
Post by Eric Warnke
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).
Post by Eric Warnke
Possible without objections
talk - protocol is getting old with IM
vi, ed, and ex are old too. Should we remove them?
Post by Eric Warnke
star - tar with acl support.
Do tar or pax provide equivalent functionality?
Nicolas Mailhot
2005-02-26 18:35:04 UTC
Permalink
Post by Chuck R. Anderson
Post by Eric Warnke
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050226/93921205/attachment.bin
Pozsár Balázs
2005-02-27 23:12:53 UTC
Permalink
Post by Nicolas Mailhot
Post by Chuck R. Anderson
Post by Eric Warnke
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.
--
pozsy
Chuck R. Anderson
2005-02-27 23:15:02 UTC
Permalink
Post by Pozsár Balázs
ncftp can do recursive get/put. Apart from that, lftp is clearly better
imho.
lftp can do recursive get, not sure about put.
Nicolas Mailhot
2005-02-28 09:10:56 UTC
Permalink
Post by Pozsár Balázs
Post by Nicolas Mailhot
Post by Chuck R. Anderson
Post by Eric Warnke
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
--
Nicolas Mailhot
Matthew Miller
2005-02-26 19:41:37 UTC
Permalink
Post by Chuck R. Anderson
Post by Eric Warnke
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 mattdm at mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Eric Warnke
2005-02-26 19:46:51 UTC
Permalink
Post by Matthew Miller
Post by Chuck R. Anderson
Post by Eric Warnke
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,
--
Eric Warnke Computer Programmer / Systems Analyst
eric at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050226/24c4ffdc/attachment.bin
Jos Vos
2005-02-26 20:05:18 UTC
Permalink
Post by Eric Warnke
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.
--
-- Jos Vos <jos at xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
Jamie Zawinski
2005-02-26 20:22:25 UTC
Permalink
Post by Eric Warnke
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 at jwz.org http://www.jwz.org/
jwz at dnalounge.com http://www.dnalounge.com/
http://jwz.livejournal.com/
Eric Warnke
2005-02-26 20:25:02 UTC
Permalink
Post by Jamie Zawinski
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,
--
Eric Warnke Computer Programmer / Systems Analyst
eric at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050226/6a403fcc/attachment.bin
Matthew Miller
2005-02-26 20:40:31 UTC
Permalink
Post by Eric Warnke
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 at mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Matthew Miller
2005-02-26 20:35:45 UTC
Permalink
Post by Eric Warnke
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.
--
Matthew Miller mattdm at mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Jocelyn Delalande
2005-02-27 17:47:16 UTC
Permalink
Post by Colin Walters
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.
I agree with you, moreover arts/gstreamer are not real solutions for
mixing (in a standard use I mean) many programs have troubles with
it... Enabling alsa mixing by default will make the ditribution more
user-friendly...

This is just my opinion
Nicolas Mailhot
2005-02-27 18:18:33 UTC
Permalink
Post by Jocelyn Delalande
Post by Colin Walters
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.
I agree with you, moreover arts/gstreamer are not real solutions for
mixing (in a standard use I mean) many programs have troubles with
it... Enabling alsa mixing by default will make the ditribution more
user-friendly...
In the meanwhile could the arts gstreamer part be separated (or moved to
extras) ? Unless FC4 is already scheduled to be 100% ALSAified ?

Regards,
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050227/353f8527/attachment.bin
Michael A. Peters
2005-02-28 03:04:12 UTC
Permalink
Post by Nicolas Mailhot
In the meanwhile could the arts gstreamer part be separated (or moved to
extras) ? Unless FC4 is already scheduled to be 100% ALSAified ?
If core is not going to be 100% alsafied then the plugin should stay in
core, so that you don't have to maintain two src.rpm's for the same
source tarball. Qt is going to be in core, so removing the arts plugin
isn't going to save space, and should not be done if there are cases
where it is needed for a functional sound system out of the box.
--
Michael A. Peters
http://mpeters.us/
Paul A. Houle
2005-02-28 16:17:00 UTC
Permalink
On Mon, 28 Feb 2005 06:04:46 -0800 (PST), Rahul Sundaram
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.
Ralf Ertzinger
2005-02-28 16:24:20 UTC
Permalink
Hi.
Post by Paul A. Houle
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.
Michael A. Peters
2005-02-28 18:58:54 UTC
Permalink
Post by Ralf Ertzinger
Hi.
Post by Paul A. Houle
source. (./configure ; make ; make install isn't much harder than
"yum
Post by Paul A. Houle
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/
Loading...