5:58 p.m.
Removed and orphaned:
asp2php - does not show any history of usage, not really a core package
Suggested for removal:
xloadimage
- there are better apps for displaying images (ImageMagick,
eog, gthumb, kview, etc)
- there are better apps for setting the root window (xsri)
- it's *ancient* code that doesn't even support PNG
nedit
- legacy interface (motif)
- doesn't support Unicode
jed
- doesn't support Unicode
Opinions?
Bill
6:01 p.m.
On Fri, 2005-01-21 at 18:58 -0500, Bill Nottingham wrote:
Removed and orphaned:
asp2php - does not show any history of usage, not really a core package
Suggested for removal:
xloadimage
- there are better apps for displaying images (ImageMagick,
eog, gthumb, kview, etc)
- there are better apps for setting the root window (xsri)
- it's *ancient* code that doesn't even support PNG
nedit
- legacy interface (motif)
- doesn't support Unicode
jed
- doesn't support Unicode
Opinions?
Blast 'em all. But please keep joe. It helped tremendously when vim
was broken a few days ago. :-)
--
-Paul Iadonisi
Senior System Administrator
Red Hat Certified Engineer / Local Linux Lobbyist
Ever see a penguin fly? -- Try Linux.
GPL all the way: Sell services, don't lease secrets
9:48 p.m.
On Fri, Jan 21, 2005 at 07:01:01PM -0500, Paul Iadonisi wrote:
Blast 'em all. But please keep joe. It helped tremendously
when vim
was broken a few days ago. :-)
It now passes the "supports unicode" litmus test, at least. :)
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
--> Fedora Users & Developers Conference, hosted by Boston University <--
February 18th, 2005 <http://fedoraproject.org/wiki/FUDCon1>
6:56 a.m.
Le samedi 22 janvier 2005 à 09:05 +0800, Peter Robinson a écrit :
> Opinions?
Yep, get rid of them. Can we also get rid / move to extras all the non
GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK
1 cruft as well?
Even better : get rid of all the stuff that doesn't use fontconfig yet
--
Nicolas Mailhot
9:05 a.m.
On Sat, Jan 22, 2005 at 09:05:19AM +0800, Peter Robinson wrote:
> Opinions?
Yep, get rid of them. Can we also get rid / move to extras all the non
GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK
1 cruft as well?
This would be wonderful but... someone has to throw some manpower at porting
gnucash from Gnome1 in order for this to happen. (This is being worked on
upstream but there is still much to be done.)
Links for porting status are here:
http://gnomesupport.org/wiki/index.php/GnuCashPortingStatus
There are other financial applications out there but I haven't looked into
whether any of these might be a suitable replacement or what the migration
cost might be.
-Toshio
10:16 p.m.
Le vendredi 21 janvier 2005 à 18:58 -0500, Bill Nottingham a écrit :
Removed and orphaned:
asp2php - does not show any history of usage, not really a core package
Suggested for removal:
(...)
nedit
- legacy interface (motif)
ddd use motif :-)
- doesn't support Unicode
jed
- doesn't support Unicode
Opinions?
Move to Fedora Extra :
dosfstools
Lynx (or elinks)
lesstif and/or openmotif21
Bill
10:51 p.m.
Le vendredi 21 janvier 2005 à 23:31 -0500, Dan Williams a écrit :
On Sat, 22 Jan 2005, [ISO-8859-1] Fliciano Matias wrote:
> ddd use motif :-)
We don't really have any other standalone graphical debuggers AFAIK, but
we do have quite a few text editors...
I love ddd :-)
I request to move lesstif and openmotif21 to Fedora Extra. But keep
openmotif (use by ddd).
Why do we keep xpdf in Fedora Core ?
gpdf works fine.
10:58 p.m.
On Sat, 2005-01-22 at 05:51 +0100, Féliciano Matias wrote:
Why do we keep xpdf in Fedora Core ?
gpdf works fine.
gpdf works with a much smaller subset of pdfs than gpdf.
There's hope, though. evince[1] will save us all from our crappy widget
PDF viewing experience.
Jeremy
[1] http://www.gnome.org/projects/evince/
6:26 a.m.
On Fri, 2005-01-21 at 23:58 -0500, Jeremy Katz wrote:
On Sat, 2005-01-22 at 05:51 +0100, Féliciano Matias wrote:
> Why do we keep xpdf in Fedora Core ?
> gpdf works fine.
gpdf works with a much smaller subset of pdfs than gpdf.
There's hope, though. evince[1] will save us all from our crappy widget
PDF viewing experience.
I've been bought by evince. The speed of it displaying PDFs is
astonishing all by it self. Also, it hasn't had any problem with none of
the PDFs I've got here, and some I had to open with xpdf, other with
gpdf (and a few with ggv).
Rui
--
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
10:59 a.m.
On Sat, Jan 22, 2005 at 05:51:03AM +0100, Féliciano Matias wrote:
I love ddd :-)
I request to move lesstif and openmotif21 to Fedora Extra. But keep
openmotif (use by ddd).
You love ddd but is it a critical base package ? The idea that "extras" ==
"inferior" has to go away to make it work well.
11:31 a.m.
Le samedi 22 janvier 2005 à 11:59 -0500, Alan Cox a écrit :
On Sat, Jan 22, 2005 at 05:51:03AM +0100, Féliciano Matias wrote:
> I love ddd :-)
> I request to move lesstif and openmotif21 to Fedora Extra. But keep
> openmotif (use by ddd).
You love ddd but is it a critical base package ?
No.
The idea that "extras" ==
"inferior" has to go away to make it work well.
You are right. ddd in Fedora Extra is fine to me.
10:04 a.m.
On Sat, 2005-01-22 at 11:59 -0500, Alan Cox wrote:
> I love ddd :-)
> I request to move lesstif and openmotif21 to Fedora Extra. But keep
> openmotif (use by ddd).
You love ddd but is it a critical base package ? The idea that
"extras" ==
"inferior" has to go away to make it work well.
Its probably time consuming to change that "extras" == "inferior"
idea;
because at the moment, we still haven't worked around to define Extras
yet
All these package removals should go on tandem with us launching Extras
officially, imho
--
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
4:31 p.m.
On Tue, Jan 25, 2005 at 12:04:02AM +0800, Colin Charles wrote:
because at the moment, we still haven't worked around to define
Extras
yet
Is there a definition of Core?
--
Norman Gaywood, Systems Administrator
School of Mathematics, Statistics and Computer Science
University of New England, Armidale, NSW 2351, Australia
norm(a)turing.une.edu.au Phone: +61 (0)2 6773 2412
http://turing.une.edu.au/~norm Fax: +61 (0)2 6773 3312
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
11:01 p.m.
On Tue, 2005-01-25 at 09:31 +1100, Norman Gaywood wrote:
> because at the moment, we still haven't worked around to
define
Extras
> yet
Is there a definition of Core?
http://fedora.redhat.com/participate/terminology.html
And we have been releasing Core for the past 3 Fedora Core's that you've
been getting, with a schedule for FC-4 out
We don't however have a released Extras _yet_ (besides Pre-Extras).
After there's a hashing out of the issues to make Extras happen (sure I
know there's terminology for it), we can start making sure that nobody
thinks of it as "inferior"
...
then the task goes on to defining Alternatives :->
--
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
9:16 a.m.
On Fri, 2005-01-21 at 23:52 -0500, Jeremy Katz wrote:
On Sat, 2005-01-22 at 05:16 +0100, Féliciano Matias wrote:
> dosfstools
Certain architectures
(*cough*ia64*cough*) require a vfat partition for booting.
Ugh! How pathetic.
--
-Paul Iadonisi
Senior System Administrator
Red Hat Certified Engineer / Local Linux Lobbyist
Ever see a penguin fly? -- Try Linux.
GPL all the way: Sell services, don't lease secrets
4:25 a.m.
On Fri, 2005-01-21 at 23:52 -0500, Jeremy Katz wrote:
On Sat, 2005-01-22 at 05:16 +0100, Féliciano Matias wrote:
> dosfstools
dosfstools is needed for anaconda. Certain architectures
(*cough*ia64*cough*) require a vfat partition for booting.
Also, it's helpful in a lot of cases where you have things like USB
keys.
+1 to that
--
Tomas Mraz <tmraz(a)redhat.com>
9:13 a.m.
On Sat, 2005-01-22 at 05:16 +0100, Féliciano Matias wrote:
[snip]
Move to Fedora Extra :
dosfstools
Er...why? Given the number of consumer devices these days that use
VFAT, I can't think of a reason why this would belong in Core. Yes, I
know they usually come pre-formatted, but I still think it's ill advised
to move out of Core a set of tools for recovering or reformatting these
media.
--
-Paul Iadonisi
Senior System Administrator
Red Hat Certified Engineer / Local Linux Lobbyist
Ever see a penguin fly? -- Try Linux.
GPL all the way: Sell services, don't lease secrets
10:35 a.m.
On Sat, 2005-01-22 at 15:13, Paul Iadonisi wrote:
On Sat, 2005-01-22 at 05:16 +0100, Féliciano Matias wrote:
[snip]
> Move to Fedora Extra :
> dosfstools
Er...why? Given the number of consumer devices these days that use
VFAT, I can't think of a reason why this would belong in Core.
I second that why ? Every USB stick, camera or floppy disk owner will
be cursing you.
Jon
10:50 a.m.
On Sat, Jan 22, 2005 at 04:35:28PM +0000, Jonathan Andrews wrote:
> Er...why? Given the number of consumer devices these days
that use
> VFAT, I can't think of a reason why this would belong in Core.
I second that why ? Every USB stick, camera or floppy disk owner will
be cursing you.
I'd second that. Its needed for so many things.
5:40 p.m.
lør, 22.01.2005 kl. 17.50 skrev Alan Cox:
On Sat, Jan 22, 2005 at 04:35:28PM +0000, Jonathan Andrews wrote:
> > Er...why? Given the number of consumer devices these days that use
> > VFAT, I can't think of a reason why this would belong in Core.
>
> I second that why ? Every USB stick, camera or floppy disk owner will
> be cursing you.
I'd second that. Its needed for so many things.
agreed. killing vfat support would be bad. It's the reason i keep
cursing Debian whenever i need to read such a disk.
Besides, vfat is imensely usefull on removable storage - you don't need
a permissions system on that stuff.
But what about mtools? Isn't that "dos-style handling of floppyes"?
noon
On Sunday 23 January 2005 00:40, Kyrre Ness Sjobak wrote:
But what about mtools? Isn't that "dos-style handling of
floppyes"?
+1
the linux way of handling removable media is just fine, we don't need drive
letters
--
http://LinuxWiki.org/RonnyBuchmann
5:44 a.m.
Le samedi 22 janvier 2005 à 11:50 -0500, Alan Cox a écrit :
On Sat, Jan 22, 2005 at 04:35:28PM +0000, Jonathan Andrews wrote:
> > Er...why? Given the number of consumer devices these days that use
> > VFAT, I can't think of a reason why this would belong in Core.
>
> I second that why ? Every USB stick, camera or floppy disk owner will
> be cursing you.
I'd second that. Its needed for so many things.
Including kickstart floppies ;) Or does this work with ext2/3 disks ?
--
Nicolas Mailhot
11:01 a.m.
On Sat, Jan 22, 2005 at 05:16:30AM +0100, Féliciano Matias wrote:
Move to Fedora Extra :
dosfstools
Lynx (or elinks)
lynx is needed for mutt to do html reading on text logins. Its also fairly
important for accessibility for some users. Elinks I wouldn't worry about
lesstif and/or openmotif21
If nothing essential still uses them definitely.
Possibly joe also ought to go to extras nowdays. It used to make sense to ship
it in base because although it had a low userbase it was the best editor on
the planet and also easy for new users. We have nano ans we have new users
in X with gedit nowdays.
Alan
11:38 a.m.
Le samedi 22 janvier 2005 à 12:01 -0500, Alan Cox a écrit :
On Sat, Jan 22, 2005 at 05:16:30AM +0100, Féliciano Matias wrote:
> lesstif and/or openmotif21
If nothing essential still uses them definitely.
With FC3 :
[fmatias@one i386]$ rpm -e --test --dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat/
lesstif
erreur: Dépendances requises:
libMrm.so.1 est nécessaire pour (déjà installé) lesstif-devel-0.93.36-6.i386
libXm.so.1 est nécessaire pour (déjà installé) lesstif-devel-0.93.36-6.i386
lesstif = 0.93.36 est nécessaire pour (déjà installé)
lesstif-devel-0.93.36-6.i386
=> lesstif is not used.
[fmatias@one i386]$ rpm -e --test --dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat/
openmotif21
(empty)
=> openmotif21 is not used.
[fmatias@one i386]$ rpm -e --test --dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat/
openmotif
erreur: Dépendances requises:
libMrm.so.3 est nécessaire pour (déjà installé) openmotif-devel-2.2.3-6.i386
libUil.so.3 est nécessaire pour (déjà installé) openmotif-devel-2.2.3-6.i386
libXm.so.3 est nécessaire pour (déjà installé) ddd-3.3.9-1.i386
libXm.so.3 est nécessaire pour (déjà installé) iiimf-le-chinput-0.3-11.i386
libXm.so.3 est nécessaire pour (déjà installé) nedit-5.4-3.i386
libXm.so.3 est nécessaire pour (déjà installé) openmotif-devel-2.2.3-6.i386
libXm.so.3 est nécessaire pour (déjà installé) stardict-1.31-21.i386
libXm.so.3 est nécessaire pour (déjà installé) xpdf-3.00-10.i386
openmotif est nécessaire pour (déjà installé) ddd-3.3.9-1.i386
openmotif = 2.2.3-6 est nécessaire pour (déjà installé)
openmotif-devel-2.2.3-6.i386
openmotif est nécessaire pour (déjà installé) stardict-1.31-21.i386
=> openmotif is used by stardict, ddd, xpdf, nedit, iiimf-le-chinput
12:30 p.m.
lynx is needed for mutt to do html reading on text logins. Its also
fairly
important for accessibility for some users. Elinks I wouldn't worry about
Also, both are key parts of my "ssh in and fix an HTML-interface-only
router" toolbox. Depending on the HTML/authentication/router, one
will work and one will not. In my experience in Freenode's #fedora,
I'm not alone in this use.
--
MG
2:14 p.m.
On Sat, 2005-01-22 at 12:30 -0600, m g wrote:
> lynx is needed for mutt to do html reading on text logins. Its
also fairly
> important for accessibility for some users. Elinks I wouldn't worry about
>
Also, both are key parts of my "ssh in and fix an HTML-interface-only
router" toolbox. Depending on the HTML/authentication/router, one
will work and one will not. In my experience in Freenode's #fedora,
I'm not alone in this use.
These kinds of comments really need to stop - it doesn't matter how
useful a utility is on your site, or even a number of users sites,
because *you can still install it from Extras*!
Removing a utility from Core is not going to in any way stop you from
doing what you need. It'll just help make sure other users don't pay
the price (bloated "core" distro) for you doing what you need.
--
MG
2:17 p.m.
On Sat, Jan 22, 2005 at 03:14:51PM -0500, Sean Middleditch wrote:
On Sat, 2005-01-22 at 12:30 -0600, m g wrote:
> > lynx is needed for mutt to do html reading on text logins. Its also fairly
> > important for accessibility for some users. Elinks I wouldn't worry about
> Also, both are key parts of my "ssh in and fix an
HTML-interface-only
> router" toolbox. Depending on the HTML/authentication/router, one
> will work and one will not. In my experience in Freenode's #fedora,
> I'm not alone in this use.
These kinds of comments really need to stop - it doesn't matter how
useful a utility is on your site, or even a number of users sites,
because *you can still install it from Extras*!
That's not the case if we are
talking about the rescue mode available
on the first installation CD of Core.
Mirek
2:21 p.m.
On Sat, 2005-01-22 at 21:17 +0100, Miloslav Trmac wrote:
On Sat, Jan 22, 2005 at 03:14:51PM -0500, Sean Middleditch wrote:
> These kinds of comments really need to stop - it doesn't matter how
> useful a utility is on your site, or even a number of users sites,
> because *you can still install it from Extras*!
That's not the case if we are talking about the rescue mode available
on the first installation CD of Core.
And the package set included in Core has roughly nothing to do with the
pre-built OS image used by the rescue system. For a rescue CD the
preferred browser would definitely be a text-based one and not
Firefox. ;-)
11:15 p.m.
Sean Middleditch (elanthis(a)awesomeplay.com) said:
And the package set included in Core has roughly nothing to do with
the
pre-built OS image used by the rescue system. For a rescue CD the
preferred browser would definitely be a text-based one and not
Firefox. ;-)
Actually, it does, since it's *built* from the Core tree at treee build
time.
Bill
9:59 a.m.
On Jan 22, 2005, Sean Middleditch <elanthis(a)awesomeplay.com> wrote:
Removing a utility from Core is not going to in any way stop you
from
doing what you need.
Only if the installer actually supports installing from extras as
well, otherwise an upgrade may be impossible, or leave the system in a
broken state.
At which point I really fail to see the point of extras: either it's
part of the distro, or it isn't. Labeling it as extras just because
it's in a separate CD is useful, because then people can choose which
CDs to download and burn upfront, but it serves no other purpose.
--
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}
10:23 a.m.
On Monday 24 January 2005 10:59, Alexandre Oliva wrote:
Only if the installer actually supports installing from extras as
well, otherwise an upgrade may be impossible, or leave the system in a
broken state.
I believe that the installer (anaconda) should support installation ONLY from
Core. Additional packages should be installed by the system-config-packages
replacement pup which would be invoked during firstboot (or manually after
firstboot). Although I have not [yet] voiced my opinion on the, I believe
that pup should support all of the same inpout modes as anaconda (e.g.,
cdrom, nfs, ftp, http, etc.).
--
Gene
10:32 a.m.
On Mon, 24 Jan 2005 11:23:46 -0500, Gene C. wrote:
On Monday 24 January 2005 10:59, Alexandre Oliva wrote:
> Only if the installer actually supports installing from extras as
> well, otherwise an upgrade may be impossible, or leave the system in a
> broken state.
I believe that the installer (anaconda) should support installation ONLY from
Core. Additional packages should be installed by the system-config-packages
replacement pup which would be invoked during firstboot (or manually after
firstboot).
And what's with extra packages which are started before firstboot?
10:52 a.m.
On Mon, 24 Jan 2005 11:32:20 -0500, seth vidal wrote:
> And what's with extra packages which are started before firstboot?
an example of these?
Daemons, firewall tools, packages which put stuff into /etc/profile.d,
for instance.
I think relying on a package to BOOT that is in extras is exactly
the
type of package that needs to not be in extras.
"Relying" is the wrong term. It's just not nice to reboot a partial
upgrade and possibly see stuff failing before you get the chance to
complete the upgrade.
10:47 a.m.
On Monday 24 January 2005 11:32, Michael Schwendt wrote:
On Mon, 24 Jan 2005 11:23:46 -0500, Gene C. wrote:
> On Monday 24 January 2005 10:59, Alexandre Oliva wrote:
> > Only if the installer actually supports installing from extras as
> > well, otherwise an upgrade may be impossible, or leave the system in a
> > broken state.
>
> I believe that the installer (anaconda) should support installation ONLY
> from Core. Additional packages should be installed by the
> system-config-packages replacement pup which would be invoked during
> firstboot (or manually after firstboot).
And what's with extra packages which are started before firstboot?
I am not sure I understand what you mean. To me, Core should provide a
working system with additional functionality available in Extras. Once I
have completed firstboot and added additional functionality, my system may
have some processes which are started before when firstboot is executed when
the system is rebooted. Extras should provide optional additional
functionality If anaconda is to handle both Core and Extras as input, then
the real distribution will be Core+Extras. Is this the intended direction?
--
Gene
10:37 a.m.
On Mon, 24 Jan 2005 11:23:46 -0500, Gene C. <czar(a)czarc.net> wrote:
I believe that the installer (anaconda) should support installation
ONLY from
Core.
Installation only? or upgrades as well?
Cleally the fresh install case isnt the problem... its the Core upgrade case.
Doing a 2 stage install is trivial... a 2 stage upgrade on the other
hand is somewhat complex, since anconda will have to leave every 3rd
party or extras package in place with broken deps until first boot can
be run in your scheme. You have to delibrately leave your system in
an inconsistent state when you reboot into it and pray that the
reboot works even though the system is in an inconsistent state.
-jef"if i ruled the world i'd make the act of upgrading a capital
punishment and require only fresh installs"spaleta
10:52 a.m.
On Monday 24 January 2005 11:37, Jeff Spaleta wrote:
On Mon, 24 Jan 2005 11:23:46 -0500, Gene C. <czar(a)czarc.net>
wrote:
> I believe that the installer (anaconda) should support installation ONLY
> from Core.
Installation only? or upgrades as well?
Cleally the fresh install case isnt the problem... its the Core upgrade
case. Doing a 2 stage install is trivial... a 2 stage upgrade on the other
hand is somewhat complex, since anconda will have to leave every 3rd party
or extras package in place with broken deps until first boot can be run in
your scheme. You have to delibrately leave your system in an inconsistent
state when you reboot into it and pray that the
reboot works even though the system is in an inconsistent state.
Oops, you are correct that I was not considering an upgrade. If we need to
handle upgrades where packages have been moved from Core to Extras but not
removed entirely, then a Fedora distribution will need to always be
Core+Extras. Is this what we want? Is this the intended direction by Fedora
developers?
I do not have answers myself and the intended direction by the folks who
"control what Fedora is" is not clear to me.
--
Gene
10:37 a.m.
At which point I really fail to see the point of extras: either
it's
part of the distro, or it isn't. Labeling it as extras just because
it's in a separate CD is useful, because then people can choose which
CDs to download and burn upfront, but it serves no other purpose.
Breaking this on CD-levels will be hard todo and of dubious benefit.
I would still expect to have more pressure to keep all software more
modular and improve the necessary support for that within our
source base. Just be warned that this is too easily confused with
only supporting the software in Core and that would be a huge
step backwards.
greetings,
Florian La Roche
10:43 a.m.
Alexandre Oliva wrote:
Only if the installer actually supports installing from extras as
well, otherwise an upgrade may be impossible, or leave the system in a
broken state.
This is one of my biggest concern with Extras.
I have no problem with many of the packages I regularly use being moved
to Extras, so long as I can use tools given to me to continue managing a
mix of packages from both Core and Extras - and that includes upgrades.
I seriously do not consider reinstalling (then adding my Extras
packages) a viable option every 6-8 months (Fedora's release cycle).
I do not have a problem with an upgrade saying: "You have non-Core
packages installed. Please specify repository locations [1] or continue
at risk of broken packages."
[1] Either "add" a CD ala debian, or point at a local directory, smb or
nfs mount point, ftp server, etc of an Extras repository for the version
of Fedora you are upgrading to (and any other repositories come to that).
At which point I really fail to see the point of extras: either
it's
part of the distro, or it isn't. Labeling it as extras just because
it's in a separate CD is useful, because then people can choose which
CDs to download and burn upfront, but it serves no other purpose.
I see Core as "packages managed mainly by RedHat employees and essential
to a base [desktop|server] system" (latter is horribly subjective I
know), and Extras as "packages mainly packaged by non-RedHat employees",
with the extra requirement that no package in Core should depend on a
package in Extras. Both are parts of the overall distribution, but Core
simply has stricter QC and inclusion requirements.
HTH
--
Stuart Children
10:46 a.m.
On Mon, 24 Jan 2005, Stuart Children wrote:
I see Core as "packages managed mainly by RedHat employees and
essential to a
base [desktop|server] system" (latter is horribly subjective I know), and
Extras as "packages mainly packaged by non-RedHat employees", with the extra
requirement that no package in Core should depend on a package in Extras.
Both are parts of the overall distribution, but Core simply has stricter QC
and inclusion requirements.
(Ironic or not) since Fedora Extras (at least the fedora.us incarnation)
actually has QA *before* packages are published, IMO, their packaging
quality is at least as good or better than many of those in Core.
--Rex
7:52 a.m.
Rex Dieter wrote:
On Mon, 24 Jan 2005, Stuart Children wrote:
> I see Core as "packages managed mainly by RedHat employees and
> essential to a base [desktop|server] system" (latter is horribly
> subjective I know), and Extras as "packages mainly packaged by
> non-RedHat employees", with the extra requirement that no package in
> Core should depend on a package in Extras. Both are parts of the
> overall distribution, but Core simply has stricter QC and inclusion
> requirements.
(Ironic or not) since Fedora Extras (at least the fedora.us incarnation)
actually has QA *before* packages are published, IMO, their packaging
quality is at least as good or better than many of those in Core.
Yes, fair point. I certainly did not intend to mark Extras as of poorer
quality (nor diminish all the hard work people have done at fedora.us).
Clearly all packagers should strive to create packages of the highest
quality - whichever repository they happen to be a part of.
My emphasis was more on who has control over packaging decisions. For
Core, that's Red Hat employees - for Extras it's the individual package
owner. Hopefully both would be working to the same guidelines/rules that
the Fedora community has agreed upon. I don't think it has to be like
that - I'm just making suggestions to try and help form definitions of
Core and Extras.
Cheers
--
Stuart Children
1:44 p.m.
New subject: Volunteers? was Re: further package removals/potential package removals
Hey, I really appreciate all the discussion about packages that could be
removed. Is there someone who's willing to read through the thread and
collecte all the proposed removals so we can examine move forward with
them?
Cheers,
-- Elliot
2:14 p.m.
New subject: Volunteers? was Re: further package removals/potential package removals
On Tue, 2005-01-25 at 14:44 -0500, Elliot Lee wrote:
Hey, I really appreciate all the discussion about packages that could
be
removed. Is there someone who's willing to read through the thread and
collecte all the proposed removals so we can examine move forward with
them?
If you don't need the list immediately, I would be happy to volunteer,
but I won't be able to get to it until the weekend.
Is that OK?
-train
4:45 p.m.
New subject: Volunteers? was Re: further package removals/potential package removals
On Tue, 25 Jan 2005 14:44:43 -0500 (EST), Elliot Lee <sopwith(a)redhat.com> wrote:
Hey, I really appreciate all the discussion about packages that could
be
removed. Is there someone who's willing to read through the thread and
collecte all the proposed removals so we can examine move forward with
them?
Read through the "further removals/potential package removals" thread
Here's the summary list of suggested removals/moves and the person who
made them.
Bill Notting:
xloadimage
nedit
jed
Peter Robinson:
Can we also get rid / move to extras all the non
GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK
1 cruft as well?
Féliciano Matias:
move to extras dosfstools
move to extras Lynx (or elinks)
move to extras lesstif and/or openmotif21
leave openmotif which is used by:
stardict, ddd, xpdf, nedit, iiimf-le-chinput
move to extras xpdf
move to extras ddd
Remove rpmdb.
move experimental gcc (gcc4 in FC3 for example) to Fedora Extra.
Alax Cox:
Possibly joe into extras
Nicolas Mailhot :
Even better : get rid of all the stuff that doesn't use fontconfig
yet
-jef
6:26 p.m.
New subject: Volunteers? was Re: further package removals/potential package removals
Le mardi 25 janvier 2005 à 17:45 -0500, Jeff Spaleta a écrit :
On Tue, 25 Jan 2005 14:44:43 -0500 (EST), Elliot Lee
<sopwith(a)redhat.com> wrote:
> Hey, I really appreciate all the discussion about packages that could be
> removed. Is there someone who's willing to read through the thread and
> collecte all the proposed removals so we can examine move forward with
> them?
Read through the "further removals/potential package removals" thread
Here's the summary list of suggested removals/moves and the person who
made them.
Bill Notting:
xloadimage
nedit
jed
Peter Robinson:
Can we also get rid / move to extras all the non
GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK
1 cruft as well?
Féliciano Matias:
Humm.
move to extras dosfstools
Forget this one. It seems very
useful for too many people.
move to extras Lynx (or elinks)
There are some objections
:
m g :
- "Also, both are key parts of my "ssh in and fix an HTML-interface-
onlyuter" toolbox. Depending on the HTML/authentication/router, one
will work and one will not. In my experience in Freenode's #fedora, I'm
not alone in this use.
Alan Cox :
- "lynx is needed for mutt to do html reading on text logins. Its also
fairlyportant for accessibility for some users."
But Luciano Miguel Ferreira Rocha reply with :
- "I prefer to use elinks on mutt:
text/html; links -dump -dump-charset iso-8859-1 -default-mime-type
text/html %s; copiousoutput;"
move to extras lesstif and/or openmotif21
Or remove. No
package in FC use lesstif or openmotif21.
leave openmotif which is used by:
stardict, ddd, xpdf, nedit, iiimf-le-chinput
move to extras xpdf
Depend on the status evince :
http://www.gnome.org/projects/evince/
btw, if evince "rocks" perhaps gpdf can also be moved to extras.
move to extras ddd
Remove rpmdb.
Or rpmdb should not provide
/usr/lib/rpmdb/i386-redhat-linux/redhat/ (97
Mo) but a tool to generate the rpmdb base (like rpmdb-fedora.spec does).
move experimental gcc (gcc4 in FC3 for example) to Fedora Extra.
Depend if experimental gcc is _only_ an experimental compiler.
In FC3 java seems to depend on gcc4.
Jeremy Katz :
- "Unfortunately, a lot of the java stuff right now is depending on gcc4
just because that's where the work is happening. Thus, tough call. On
the note of the free java stuff... gcj is really coming along
impressively in the things it can run now."
Alax Cox:
Possibly joe into extras
Nicolas Mailhot :
Even better : get rid of all the stuff that doesn't use fontconfig
yet
-jef
2:59 a.m.
New subject: Volunteers? was Re: further package removals/potential package removals
Le mardi 25 janvier 2005 à 17:45 -0500, Jeff Spaleta a écrit :
On Tue, 25 Jan 2005 14:44:43 -0500 (EST), Elliot Lee
<sopwith(a)redhat.com> wrote:
Féliciano Matias:
move to extras lesstif and/or openmotif21
leave openmotif which is used by:
stardict, ddd, xpdf, nedit, iiimf-le-chinput
I'm afraid openmotif21 is still used by big closed packages like Oracle.
Not that is matters much for FC, but it almost ensured a continued RHEL
existence, and at this point if a package is in RHEL it can as well be
kept in FC (since it will be maintained by RH, and it's nice to allow
people to experiment replacing RHEL with FC for test setups even if
certification grids force the use of RHEL in prod)
Regards,
--
Nicolas Mailhot
3:57 p.m.
New subject: Volunteers? was Re: further package removals/potential package removals
Hey Jef, thanks for compiling this list!
On Tue, 25 Jan 2005, Jeff Spaleta wrote:
Bill Notting:
xloadimage
nedit
jed
jed to extras once that process works, but probably needs to stick around
until then. The others look right.
Peter Robinson:
Can we also get rid / move to extras all the non
GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK
1 cruft as well?
Need specific package nominations.
F�liciano Matias:
move to extras dosfstools
This one is needed as mentioned on the list.
move to extras Lynx (or elinks)
These (and w3m) each have particular quirks that apparently make them all
worthy of inclusion.
move to extras lesstif and/or openmotif21
openmotif21 may be needed for compatibility. lesstif sounds fine so we'll
see.
leave openmotif which is used by:
stardict, ddd, xpdf, nedit, iiimf-le-chinput
move to extras xpdf
We'll wait until evince gets in.
move to extras ddd
I think it needs to be maintained in Core for now, as it's the only
graphical debugger worth much.
Remove rpmdb.
This is useful to some people and is especially needed for building x86_64
trees.
move experimental gcc (gcc4 in FC3 for example) to Fedora Extra.
No, this is needed for java stuff.
Alax Cox:
Possibly joe into extras
Same deal as jed, I suspect.
Nicolas Mailhot :
Even better : get rid of all the stuff that doesn't use fontconfig
yet
Need specific package nominations, please.
The list so far: xloadimage nedit lesstif
Cheers,
-- Elliot
4:18 p.m.
New subject: Volunteers? was Re: further package removals/potential package removals
On Mon, 31 Jan 2005 16:57:57 -0500 (EST), Elliot Lee <sopwith(a)redhat.com> wrote:
> Peter Robinson:
> Can we also get rid / move to extras all the non
> GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK
> 1 cruft as well?
Need specific package nominations.
The gtk1 apps dead horse has been beaten in the grip removal thread.
As far as end-user applications that require gtk1 the potential list
Peter Robinson would be
talking about are:
xmms ( gtk2 based bmp exists as replacement for functionality
but is not a 100% feature replacement
some noted usability deficiencies in moving to bmp )
gnucash ( a beast of a beast and there has been no discussion
of a suitable replacement for its functionality)
usbview ( no discussion that I've seen )
mtr-gtk ( no discussion that I've seen )
sylpheed ( no discussion that I've seen )
w3m-img (no discussion that I've seen)
nmap-frontend (no discussion that I've seen )
as summaried from Colin Charles full list of packages that require the
gtk+-1.2.10 package:
bonobo-1.0.22-9.i386
cdicconf-0.2-9.i386
GConf-1.0.9-15.i386
gdk-pixbuf-0.22.0-15.0.i386
gdk-pixbuf-gnome-0.22.0-15.0.i386
gnome-libs-1.4.1.2.90-44.i386
gnome-print-0.37-10.i386
gnome-vfs-1.0.5-21.i386
gnucash-1.8.9-2.i386
gtk+-1.2.10-33.i386
gtk+-devel-1.2.10-33.i386
gtk-engines-0.12-5.i386
gtkhtml-1.1.9-10.i386
Guppi-0.40.3-21.i386
imlib-1.9.13-21.i386
libdv-tools-0.103-1.i386
libgal23-0.24-4.i386
libglade-0.17-15.i386
libgnomeprint15-0.37-10.i386
mtr-gtk-0.54-10.i386
nmap-frontend-3.70-1.i386
sylpheed-0.9.12-1.i386
usbview-1.0-13.i386
w3m-img-0.5.1-4.FC3.1.i386
xmms-1.2.10-9.i386
xmms-flac-1.1.0-7.i386
-jef
4:43 p.m.
New subject: Volunteers? was Re: further package removals/potential package removals
Jeff Spaleta (jspaleta(a)gmail.com) said:
usbview ( no discussion that I've seen )
Could probably be very simply ported.
mtr-gtk ( no discussion that I've seen )
A GTK app that only works if run as root. Frankly, it should
just be taken out and shot.
sylpheed ( no discussion that I've seen )
I believe this was mentioned along with balsa in an
earlier message.
Bill
4:20 p.m.
New subject: Volunteers? was Re: further package removals/potential package removals
On Mon, Jan 31, 2005 at 04:57:57PM -0500, Elliot Lee wrote:
> Peter Robinson:
> Can we also get rid / move to extras all the non
> GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK
> 1 cruft as well?
Need specific package nominations.
nmap-frontend is one.
gnucash we're waiting on the port to gtk2
John Thacker
7:55 p.m.
New subject: Volunteers? was Re: further package removals/potential package removals
> > Can we also get rid / move to extras all the non
> > GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK
> > 1 cruft as well?
>
> Need specific package nominations.
nmap-frontend is one.
gnucash we're waiting on the port to gtk2
Can't it go into extras in the mean time as extras isn't suppose to be
second class but rather 'extras' that way all the GNOME 1.x stuff
listed above can go with it. Those that need it can then just do an
'up2date -i gnucash' and get all the deps that go with it.
It seems its easier to get rid of all the GNOME 1 stuff than the
gtk/glib 1 stuff as its used by the likes of imlib and a few others.
I seem to remember that sylpheed was also mentioned a while a go as
part of the move to extras.
P
8:55 p.m.
New subject: Volunteers? was Re: further package removals/potential package removals
On Tue, 2005-02-01 at 09:55 +0800, Peter Robinson wrote:
> > > Can we also get rid / move to extras all the non
> > > GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK
> > > 1 cruft as well?
> >
> > Need specific package nominations.
>
> nmap-frontend is one.
> gnucash we're waiting on the port to gtk2
Can't it go into extras in the mean time as extras isn't suppose to be
second class but rather 'extras' that way all the GNOME 1.x stuff
listed above can go with it. Those that need it can then just do an
'up2date -i gnucash' and get all the deps that go with it.
If people are going to continue to say that "one app to perform a
function" in Core is a goal, then gnucash ought to stay. Gnucash is the
only package in Core that is a full-featured financial app. There are
two things that can be done to help rectify the gnucash situation:
sample grisbi and other financial apps to see if any of them are capable
of taking gnucash's place or take a look at what needs to be done to
finish porting gnucash to Gtk2 and help out::
http://gnomesupport.org/wiki/index.php/GnuCashPortingStatus
-Toshio
--
5:57 a.m.
New subject: Volunteers? was Re: further package removals/potential package removals
John Thacker wrote:
On Mon, Jan 31, 2005 at 04:57:57PM -0500, Elliot Lee wrote:
>>Peter Robinson:
>> Can we also get rid / move to extras all the non
>> GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK
>> 1 cruft as well?
>
>Need specific package nominations.
nmap-frontend is one.
porting to gtk2 should not be too hard...
10:04 a.m.
New subject: Volunteers? was Re: further package removals/potential package removals
Harald Hoyer wrote:
John Thacker wrote:
> nmap-frontend is one.
porting to gtk2 should not be too hard...
Ok, evil quickported nmapfe to gtk2. Maybe some gtk freak could look after it,
so that it can compile without "-DGTK_ENABLE_BROKEN" (configure.ac) and
runtime errors and warnings.
10:06 a.m.
New subject: Volunteers? was Re: further package removals/potential package removals
On Wed, Feb 02, 2005 at 05:04:08PM +0100, Harald Hoyer wrote:
Ok, evil quickported nmapfe to gtk2. Maybe some gtk freak could look
after it,
so that it can compile without "-DGTK_ENABLE_BROKEN" (configure.ac) and
runtime errors and warnings.
Do we actually care about runtime warnings? There hardly seems to be a
gtk program that does not produce them.
5:55 a.m.
New subject: Volunteers? was Re: further package removals/potential package removals
ons, 02,.02.2005 kl. 17.06 +0100, skrev Ralf Ertzinger:
On Wed, Feb 02, 2005 at 05:04:08PM +0100, Harald Hoyer wrote:
> Ok, evil quickported nmapfe to gtk2. Maybe some gtk freak could look after it,
> so that it can compile without "-DGTK_ENABLE_BROKEN" (configure.ac) and
> runtime errors and warnings.
Do we actually care about runtime warnings? There hardly seems to be a
gtk program that does not produce them.
We should, and filing bugs about them in bugzilla.gnome.org gets them
fixed some times depending on the severity of the warning.
If we're fixing compile time warnings, why shouldn't we be fixing run-
time ones?
Cheers
Kjartan
12:51 p.m.
New subject: Volunteers? was Re: further package removals/potential package removals
On Mon, 31 Jan 2005, John Thacker wrote:
On Mon, Jan 31, 2005 at 04:57:57PM -0500, Elliot Lee wrote:
> > Peter Robinson:
> > Can we also get rid / move to extras all the non
> > GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK
> > 1 cruft as well?
>
> Need specific package nominations.
nmap-frontend is one.
gnucash we're waiting on the port to gtk2
gnucash is staying in core for now because the maintainer says so. :) (I
assume this means that the gtk2 port is forthcoming.)
nmap-frontend in rawhide uses gtk2, so no worries there.
Thanks,
-- Elliot
2:20 a.m.
New subject: Volunteers? was Re: further package removals/potential package removals
On 02/03/2005 10:51:31 AM, Elliot Lee wrote:
> gnucash we're waiting on the port to gtk2
gnucash is staying in core for now because the maintainer says so. :)
(I
assume this means that the gtk2 port is forthcoming.)
Even if a gtk2 port is not forthcoming, it is really the only mature
app that does what it does.
6:55 a.m.
New subject: Volunteers? was Re: further package removals/potential package removals
On Fri, 4 Feb 2005, Michael A. Peters wrote:
On 02/03/2005 10:51:31 AM, Elliot Lee wrote:
> > gnucash we're waiting on the port to gtk2
>
> gnucash is staying in core for now because the maintainer says so. :)
> (I
> assume this means that the gtk2 port is forthcoming.)
Even if a gtk2 port is not forthcoming, it is really the only mature app that
does what it does.
kmymoney2 is pretty nice (I suppose I should submit it to extras now that
I opened my mouth).
-- Rex
4:22 p.m.
New subject: Volunteers? was Re: further package removals/potential package removals
On Mon, 31 Jan 2005, Elliot Lee wrote:
> Possibly joe into extras
Same deal as jed, I suspect.
Hopefully not :). Joe is about the only useful text editor out there;
pico is too feature-poor, emacs is too big, and Real Men don't want to
touch vi if it can be avoided.
/runs before someone starts flaming.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
4:25 p.m.
New subject: Volunteers? was Re: further package removals/potential package removals
On Tue, 2005-02-01 at 00:22 +0200, Pekka Savola wrote:
On Mon, 31 Jan 2005, Elliot Lee wrote:
>> Possibly joe into extras
>
> Same deal as jed, I suspect.
Hopefully not :). Joe is about the only useful text editor out there;
pico is too feature-poor, emacs is too big, and Real Men don't want to
touch vi if it can be avoided.
/runs before someone starts flaming.
it's not going away.
it would just be leaving core.
going to extras.
that's all.
heck, YOU could maintain it in extras if you wanted.
wouldn't that be cool?
-sv
4:36 p.m.
New subject: Volunteers? was Re: further package removals/potential package removals
On Tue, Feb 01, 2005 at 12:22:30AM +0200, Pekka Savola wrote:
pico is too feature-poor, emacs is too big, and Real Men don't
want to
touch vi if it can be avoided. ^^^^^^^^
Ahem, err -- I think that should read 'Girly Man' instead... :)
--
Dimi.
4:26 p.m.
New subject: Volunteers? was Re: further package removals/potential package removals
On Mon, 31 Jan 2005 16:57:57 -0500 (EST), Elliot Lee <sopwith(a)redhat.com> wrote:
Hey Jef, thanks for compiling this list!
On Tue, 25 Jan 2005, Jeff Spaleta wrote:
> Bill Notting:
> xloadimage
> nedit
> jed
jed to extras once that process works, but probably needs to stick around
until then. The others look right.
> Peter Robinson:
> Can we also get rid / move to extras all the non
> GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK
> 1 cruft as well?
Need specific package nominations.
> Féliciano Matias:
> move to extras dosfstools
This one is needed as mentioned on the list.
> move to extras Lynx (or elinks)
These (and w3m) each have particular quirks that apparently make them all
worthy of inclusion.
> move to extras lesstif and/or openmotif21
openmotif21 may be needed for compatibility. lesstif sounds fine so we'll
see.
> leave openmotif which is used by:
> stardict, ddd, xpdf, nedit, iiimf-le-chinput
> move to extras xpdf
We'll wait until evince gets in.
> move to extras ddd
I think it needs to be maintained in Core for now, as it's the only
graphical debugger worth much.
> Remove rpmdb.
This is useful to some people and is especially needed for building x86_64
trees.
> move experimental gcc (gcc4 in FC3 for example) to Fedora Extra.
No, this is needed for java stuff.
> Alax Cox:
> Possibly joe into extras
Same deal as jed, I suspect.
> Nicolas Mailhot :
> Even better : get rid of all the stuff that doesn't use fontconfig
> yet
Need specific package nominations, please.
The list so far: xloadimage nedit lesstif
Cheers,
-- Elliot
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Nick Bargnesi
http://www.den-4.com
Den 4 Software
pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi(a)gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0
sub 2048g/56C5D45B 2004-12-02
dd if=/dev/zero of=/dev/hda
4:30 p.m.
New subject: Volunteers? was Re: further package removals/potential package removals
On Mon, 31 Jan 2005 16:57:57 -0500 (EST), Elliot Lee
<sopwith(a)redhat.com> wrote:
Hey Jef, thanks for compiling this list!
On Tue, 25 Jan 2005, Jeff Spaleta wrote:
> Bill Notting:
> xloadimage
> nedit
> jed
jed to extras once that process works, but probably needs to stick around
until then. The others look right.
> Peter Robinson:
> Can we also get rid / move to extras all the non
> GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK
> 1 cruft as well?
Need specific package nominations.
> Féliciano Matias:
> move to extras dosfstools
This one is needed as mentioned on the list.
> move to extras Lynx (or elinks)
These (and w3m) each have particular quirks that apparently make them all
worthy of inclusion.
> move to extras lesstif and/or openmotif21
openmotif21 may be needed for compatibility. lesstif sounds fine so we'll
see.
I know of quite a few applications using openmotif that standardize on
Red Hat / Fedora Core distributions. Is the suggestion to remove 2.1
keeping 2.2?
> leave openmotif which is used by:
> stardict, ddd, xpdf, nedit, iiimf-le-chinput
> move to extras xpdf
We'll wait until evince gets in.
> move to extras ddd
I think it needs to be maintained in Core for now, as it's the only
graphical debugger worth much.
> Remove rpmdb.
This is useful to some people and is especially needed for building x86_64
trees.
> move experimental gcc (gcc4 in FC3 for example) to Fedora Extra.
No, this is needed for java stuff.
> Alax Cox:
> Possibly joe into extras
Same deal as jed, I suspect.
> Nicolas Mailhot :
> Even better : get rid of all the stuff that doesn't use fontconfig
> yet
Need specific package nominations, please.
The list so far: xloadimage nedit lesstif
Cheers,
-- Elliot
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Nick Bargnesi
http://www.den-4.com
Den 4 Software
pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi(a)gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0
sub 2048g/56C5D45B 2004-12-02
dd if=/dev/zero of=/dev/hda
4:31 p.m.
New subject: Volunteers? was Re: further package removals/potential package removals
>
> openmotif21 may be needed for compatibility. lesstif sounds fine so we'll
> see.
I know of quite a few applications using openmotif that standardize on
Red Hat / Fedora Core distributions. Is the suggestion to remove 2.1
keeping 2.2?
And there's no reason they can't go on doing this.
they'll just to have make sure extras is enabled in their yum
repositories and:
yum install openmotif\*
-sv
1:35 p.m.
On Sat, 2005-01-22 at 12:01 -0500, Alan Cox wrote:
[snip]
Possibly joe also ought to go to extras nowdays. It used to make
sense to ship
it in base because although it had a low userbase it was the best editor on
the planet and also easy for new users. We have nano ans we have new users
in X with gedit nowdays.
I can deal with that. I forgot about nano. As long as there is one
alternative (and *small*) text editor besides vi (vim). I like vim, but
was astonished by how utterly dependent I am on it when it was broken a
few days ago. Then I remembered joe ... saved the day for me. Nano can
serve that role, too.
--
-Paul Iadonisi
Senior System Administrator
Red Hat Certified Engineer / Local Linux Lobbyist
Ever see a penguin fly? -- Try Linux.
GPL all the way: Sell services, don't lease secrets
2:12 p.m.
On Sat, 2005-01-22 at 14:35 -0500, Paul Iadonisi wrote:
I can deal with that. I forgot about nano. As long as there is
one
alternative (and *small*) text editor besides vi (vim). I like vim, but
was astonished by how utterly dependent I am on it when it was broken a
few days ago. Then I remembered joe ... saved the day for me. Nano can
serve that role, too.
The proper fix for that break (libperl) to make sure that such an
essential utility stays working in the future would be to check for
libperl at runtime and dlopen() it. The Vim folks might take a patch
(or bug report) for that. Then if libperl breaks (it can happen even
outside of Rawhide when you make certain kinds of mistakes) the standard
UNIX text editor will still work.
4:14 p.m.
Alan Cox wrote:
On Sat, Jan 22, 2005 at 05:16:30AM +0100, Féliciano Matias wrote:
>Move to Fedora Extra :
>dosfstools
>Lynx (or elinks)
lynx is needed for mutt to do html reading on text logins. Its also fairly
important for accessibility for some users. Elinks I wouldn't worry about
Lynx is also an important application for when one is not capable of
using a GUI to browse html sites. I find the program valuble and not
"cruft".
Mc is a very handy cli application also and should be included in the
core installation.
Is the concept of Fedora Extras to push programs off to the side or to
find a better location for programs that are close to the upstream
developers model in containment?
Is there work in making compatible iso files for Fedora Extras to enable
installing them during an initial fresh installation?
programs for inclusion from my point are xorg-x11, gedit, mc, mozilla
(full suite), lynx, various server applications, up2date (or a better,
configurable, GUI capable updating tool.)
Jim
Alan
5:04 a.m.
Jim Cornette wrote:
Is the concept of Fedora Extras to push programs off to the side or
to
find a better location for programs that are close to the upstream
developers model in containment?
Proving the concept/integration before moving a lot of things there
would be good.
Is there work in making compatible iso files for Fedora Extras to
enable installing them during an initial fresh installation?
And, FWIW, it should be available during kickstart too.
9:59 p.m.
On Sat, 2005-01-22 at 12:01 -0500, Alan Cox wrote:
Possibly joe also ought to go to extras nowdays.
Is there any
wordstar compatible editor in Core?
To me, seeing joe removed would be a severe regression. >15 years of
using wordstar compatible editors can't simply be ignored.
Ralf
10:11 p.m.
On Sun, 2005-01-23 at 04:59 +0100, Ralf Corsepius wrote:
On Sat, 2005-01-22 at 12:01 -0500, Alan Cox wrote:
> Possibly joe also ought to go to extras nowdays.
Is there any wordstar compatible editor in Core?
To me, seeing joe removed would be a severe regression. >15 years of
using wordstar compatible editors can't simply be ignored.
So install it from Extras. It's preclusion from Core will not cause a
retroactive obliteration of every copy of joe in the known world, nor
hinder you in the least from installing it whenever you want from
Extras.
Why is this not getting through to people? Is "extras" a synonym for
"/dev/null" in half the world or something? ;-)
10:36 p.m.
Once upon a time, Sean Middleditch <elanthis(a)awesomeplay.com> said:
So install it from Extras. It's preclusion from Core will not
cause a
retroactive obliteration of every copy of joe in the known world, nor
hinder you in the least from installing it whenever you want from
Extras.
Why is this not getting through to people? Is "extras" a synonym for
"/dev/null" in half the world or something? ;-)
Just because _you_ don't think it should be in Core doesn't mean that it
in fact should be removed. Why do you think you get to dictate what
gets moved to Extras and anyone that disagrees with you is wrong?
To quote from the Fedora website:
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.
...
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.)
These are objectives of Fedora _Core_, not Fedora Extras.
Do "competing operating systems" include joe? I would say yes; joe has
been included in most Linux distributions for years. If you install the
Solaris 9 "Sun Freeware" collection, you get joe.
Is it a popular package? It sounds like it.
Is it already included in Red Hat's commecially support products? It is
in RHEL 3.
In any case, until Fedora Extras fully materializes, I think it is a
moot point. I would like to see a release with FC and FE released at
the same time (with FE being based on the current "pre-Extras") and FE
fully operational _before_ packages start migrating from Core to Extras.
We need to see how well FE really works before pushing a bunch of
packages out of FC. I think we also need anaconda to handle installing
from FE ISOs during install to make things as seamless as possible.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
12:08 a.m.
On Sunday 23 January 2005 12:36, Chris Adams wrote:
In any case, until Fedora Extras fully materializes, I think it is a
moot point. I would like to see a release with FC and FE released at
the same time (with FE being based on the current "pre-Extras") and
FE fully operational _before_ packages start migrating from Core to
Extras.
+1
--
-jeff
3:13 a.m.
On Saturday 22 January 2005 23:36, Chris Adams wrote:
Once upon a time, Sean Middleditch <elanthis(a)awesomeplay.com>
said:
> So install it from Extras. It's preclusion from Core will not cause a
> retroactive obliteration of every copy of joe in the known world, nor
> hinder you in the least from installing it whenever you want from
> Extras.
>
> Why is this not getting through to people? Is "extras" a synonym for
> "/dev/null" in half the world or something? ;-)
Just because _you_ don't think it should be in Core doesn't mean that it
in fact should be removed. Why do you think you get to dictate what
gets moved to Extras and anyone that disagrees with you is wrong?
To quote from the Fedora website:
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.
...
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.)
These are objectives of Fedora _Core_, not Fedora Extras.
Do "competing operating systems" include joe? I would say yes; joe has
been included in most Linux distributions for years. If you install the
Solaris 9 "Sun Freeware" collection, you get joe.
Is it a popular package? It sounds like it.
Is it already included in Red Hat's commecially support products? It is
in RHEL 3.
In any case, until Fedora Extras fully materializes, I think it is a
moot point. I would like to see a release with FC and FE released at
the same time (with FE being based on the current "pre-Extras") and FE
fully operational _before_ packages start migrating from Core to Extras.
We need to see how well FE really works before pushing a bunch of
packages out of FC. I think we also need anaconda to handle installing
from FE ISOs during install to make things as seamless as possible.
Agree! Agree!
With all of this discussion of moving packages from Core to Extras, I thought
I better take another look at Extras (last time I looked, Extras for FC3 was
empty). So there is now an Extras for FC3 ... BUT where are the
corresponding SRPMS??!!
Let me go further and say that if Fedora Extras is to be the "partner" of
Fedora Core, then it should be on the same mirrors as Fedora Core. I am not
sure what a good structure should be but the Fedora directory tree should
inlcude a Core branch and an Extras branch.
--
Gene
3:59 a.m.
On Sun, 2005-01-23 at 04:13 -0500, Gene C. wrote:
With all of this discussion of moving packages from Core to Extras, I
thought
I better take another look at Extras (last time I looked, Extras for FC3 was
empty). So there is now an Extras for FC3 ... BUT where are the
corresponding SRPMS??!!
The content in download.fedora.us is just a mirror primarily for the
benefit of apt users. The pre-extras master site has the source RPMS,
see http://fedoraproject.org/pre-extras/3/, i386/srpms, and
x86_64/srpms. No, I don't know why it was made this way, and I hope
it's a temporary arrangement that will change in the near future
(meaning both availability of the SRPMS in the fedora.us mirror as well
as moving the SRPMS into a dir where users expect to see them in the
master).
Let me go further and say that if Fedora Extras is to be the
"partner" of
Fedora Core, then it should be on the same mirrors as Fedora Core. I am not
sure what a good structure should be but the Fedora directory tree should
inlcude a Core branch and an Extras branch.
This is being worked on.
11:04 p.m.
On Sat, 2005-01-22 at 23:11 -0500, Sean Middleditch wrote:
On Sun, 2005-01-23 at 04:59 +0100, Ralf Corsepius wrote:
> On Sat, 2005-01-22 at 12:01 -0500, Alan Cox wrote:
>
> > Possibly joe also ought to go to extras nowdays.
> Is there any wordstar compatible editor in Core?
>
> To me, seeing joe removed would be a severe regression. >15 years of
> using wordstar compatible editors can't simply be ignored.
So install it from Extras. It's preclusion from Core will not cause a
retroactive obliteration of every copy of joe in the known world, nor
hinder you in the least from installing it whenever you want from
Extras.
You are missing my point: Which packages to go into Core is subject of
personal perspective/perception.
FC contains a lot of packages I don't have much use for or care much
about, unless they conflict or cause damage. For those, I don't really
care much about whether they are part of Core or Extras.
However, one minimal requirement I impose on a distribution is having a
wordstar compatible editor. Therefore to me, removing "joe" from Core
without substitute, is more than "substituting on package by another",
it is crippling the distribution.
To put the other way round: How you would feel if somebody proposes to
remove vi or emacs without substitute? That's the situation I am facing.
Why is this not getting through to people? Is "extras" a
synonym for
"/dev/null" in half the world or something? ;-)
Before it is
implemented, to some extend yes ;-)
Of cause extras is not a synonym of /dev/null!
It's just that removing joe from Core to me means FC is going to deviate
from my demands and therefore means a step towards becoming less
attractive.
Ralf
12:53 p.m.
Sean Middleditch wrote:
So install it from Extras. It's preclusion from Core will not
cause a
retroactive obliteration of every copy of joe in the known world, nor
hinder you in the least from installing it whenever you want from
Extras.
Why is this not getting through to people? Is "extras" a synonym for
"/dev/null" in half the world or something? ;-)
I'm a joe user, and I would like to see it removed from Core, but I also
have no problem in having it in Extras. However, as it stands now,
"extras" is a synonym for "/dev/null". I'll only believe it when I
see
it. There should be an official "extras" before people start moving core
packages onto it.
Carlos Rodrigues
6:47 a.m.
On Sun, Jan 23, 2005 at 04:59:56AM +0100, Ralf Corsepius wrote:
On Sat, 2005-01-22 at 12:01 -0500, Alan Cox wrote:
> Possibly joe also ought to go to extras nowdays.
Is there any wordstar compatible editor in Core?
To me, seeing joe removed would be a severe regression. >15 years of
using wordstar compatible editors can't simply be ignored.
Sure but those of use who've been using 15 plus years of w* compatible
editors can probably work extras just fine
11:55 p.m.
On Sun, 2005-01-23 at 04:59 +0100, Ralf Corsepius wrote:
On Sat, 2005-01-22 at 12:01 -0500, Alan Cox wrote:
> Possibly joe also ought to go to extras nowdays.
Is there any wordstar compatible editor in Core?
To me, seeing joe removed would be a severe regression. >15 years of
using wordstar compatible editors can't simply be ignored.
The old way of thinking about this has got to go. _Moving_ something to
Extras is not the same thing as removing it from the distro.
We have got to stop thinking of moving something to Extras as removing
it from the distro. Core is not the distro, it is merely a part of the
distro. Extras is another part.
--
Peter
1:37 a.m.
On Mon, 2005-01-24 at 00:55 -0500, Peter Jones wrote:
On Sun, 2005-01-23 at 04:59 +0100, Ralf Corsepius wrote:
> On Sat, 2005-01-22 at 12:01 -0500, Alan Cox wrote:
>
> > Possibly joe also ought to go to extras nowdays.
> Is there any wordstar compatible editor in Core?
>
> To me, seeing joe removed would be a severe regression. >15 years of
> using wordstar compatible editors can't simply be ignored.
The old way of thinking about this has got to go. _Moving_ something to
Extras is not the same thing as removing it from the distro.
Well, that's not
the problem.
The problem is removing "joe" means abandoning a whole family of
editors, which once had been the world's dominating family of editors
and had sustainably influenced a whole generation of users.
I.e. the problem is not RH moving a package from Core to Extras, the
problem is RH abandoning a Core system feature (Here: wordstar-
compatible ascii text editors.)
On the other hand, RH/Core seems to be wanting to continue shipping
various other editors, such as vim (which has had a lot of problems in
the past), and bloated blobs like emacs and xemacs.
IMO, if you want to remove joe from Core, you should be consequent and
remove vi, emacs, xemacs, etc. too and let only ship one single, small
and statically linked ascii text-editor remain in Core, may-be nano.
Otherwise I would recommend to remove nano, because I don't see any
reason why it should be integrated into Core.
We have got to stop thinking of moving something to Extras as
removing
it from the distro. Core is not the distro, it is merely a part of the
distro. Extras is another part.
ATM, Extras isn't much more than a
"promise", ... we will see if it will
come and if when it will work out.
Ralf
10:08 a.m.
On Jan 24, 2005, seth vidal <skvidal(a)phy.duke.edu> wrote:
> ATM, Extras isn't much more than a "promise", ...
we will see if it will
> come and if when it will work out.
just consider pre-extras as 'extras' for now.
I thought current pre-extras was for FC3. Do we have a separate tree
I'm not aware of tracking rawhide?
--
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}
10:19 a.m.
On Mon, 2005-01-24 at 14:08 -0200, Alexandre Oliva wrote:
On Jan 24, 2005, seth vidal <skvidal(a)phy.duke.edu> wrote:
>> ATM, Extras isn't much more than a "promise", ... we will see if
it will
>> come and if when it will work out.
> just consider pre-extras as 'extras' for now.
I thought current pre-extras was for FC3. Do we have a separate tree
I'm not aware of tracking rawhide?
Frankly, I'd be happy to install a rawhide chroot and build from there
but we don't have enough people involved to really make it flow. If
you'd like to help out in that then figure out what the hold up to
getting more people signed on under the CLA.
-sv
10:30 a.m.
On Mon, 24 Jan 2005 08:35:33 -0500, seth vidal wrote:
> ATM, Extras isn't much more than a "promise", ...
we will see if it will
> come and if when it will work out.
just consider pre-extras as 'extras' for now.
It's called "pre-Extras", nothing more, and we're still in the middle
of nowhere.
CVS is a step forward. Pre-Extras is a step backward. At fedora.us we
have the stable/testing/unstable classification and the separate
"pending" repositories, which we can use rather freely. With
pre-Extras, we don't even have a package submission policy. Package
updates for pre-Extras are done via bugzilla.fedora.us, because
nothing else is documented and CVS has not even been opened for
fedora.us trusted developers yet.
It is my impression some key people wait for FUDCon and hope for
wonders. While that may be an option for those who plan the official
Fedora Extras and else have not been involved so far, it is unbearable
for the active fedora.us and pre-extras supporters.
10:48 a.m.
It's called "pre-Extras", nothing more, and we're
still in the middle
of nowhere.
CVS is a step forward. Pre-Extras is a step backward. At fedora.us we
have the stable/testing/unstable classification and the separate
"pending" repositories, which we can use rather freely. With
pre-Extras, we don't even have a package submission policy. Package
updates for pre-Extras are done via bugzilla.fedora.us, because
nothing else is documented and CVS has not even been opened for
fedora.us trusted developers yet.
Why are package updates for pre-extras done by bugzilla.fedora.us. All
the packages in cvs are in red hat's bugzilla.
It is my impression some key people wait for FUDCon and hope for
wonders. While that may be an option for those who plan the official
Fedora Extras and else have not been involved so far, it is unbearable
for the active fedora.us and pre-extras supporters.
Where did you get this impression from?
I'm sorry to hear you don't like pre-extras, I was trying to help out by
building those things and putting them up.
-sv
11:29 a.m.
On Mon, 24 Jan 2005 11:48:20 -0500, seth vidal wrote:
> It's called "pre-Extras", nothing more, and
we're still in the middle
> of nowhere.
>
> CVS is a step forward. Pre-Extras is a step backward. At fedora.us we
> have the stable/testing/unstable classification and the separate
> "pending" repositories, which we can use rather freely. With
> pre-Extras, we don't even have a package submission policy. Package
> updates for pre-Extras are done via bugzilla.fedora.us, because
> nothing else is documented and CVS has not even been opened for
> fedora.us trusted developers yet.
Why are package updates for pre-extras done by bugzilla.fedora.us. All
the packages in cvs are in red hat's bugzilla.
Please enlighten me. How did the package release procedure change
between fedora.us and pre-extras? Who does what? And where?
> It is my impression some key people wait for FUDCon and hope
for
> wonders. While that may be an option for those who plan the official
> Fedora Extras and else have not been involved so far, it is unbearable
> for the active fedora.us and pre-extras supporters.
Where did you get this impression from?
I'm sorry to hear you don't like pre-extras, I was trying to help out by
building those things and putting them up.
No, no, I'm glad that we have your FC3 builds in the pre-extras tree.
Surely better than no FC3 builds at all. And e.g. Dave Lawrence's
response time on requests for adding bugzilla components is
awesome. But let me repeat. I've said before at least once that if
Fedora Extras and its buildsystem need more time, we should keep
fedora.us running, simplifying procedures where reasonable,
continueing to grow. However, with intermediate steps like pre-extras,
promises, and no clear guidance we continue to kill off fedora.us
while Fedora Extras is not ready. As much as I'd like to migrate to
less burdensome procedures (for all of us!), currently some of us
"fight" at two fronts. New contributors don't know at all what to
do. And existing contributors, including so-called trusted ones at
fedora.us, are somewhere inbetween.
11:11 a.m.
Le lundi 24 janvier 2005 à 17:30 +0100, Michael Schwendt a écrit :
At fedora.us we
have the stable/testing/unstable classification
Fedora Core don't have such "stable/testing/unstable classification" and
I think it's a good thing.
Debian have this "feature" I am not convinced it's very useful.
11:45 a.m.
On Mon, 24 Jan 2005 18:11:08 +0100, Féliciano Matias wrote:
Le lundi 24 janvier 2005 à 17:30 +0100, Michael Schwendt a écrit :
> At fedora.us we
> have the stable/testing/unstable classification
Fedora Core don't have such "stable/testing/unstable classification" and
I think it's a good thing.
Sorry that you disagree, but as someone who has reviewed and approved
several hundreds of packages at fedora.us, it is my opinion that the
classification (at least the split into stable+testing) has been
beneficial. Also at rpm.livna.org it permitted test-driving new
releases publicly while not disturbing known good releases. It
utilises existing community resources, who are interested in
contributing community QA, while other parts of the community prefer
not to play with fire.
Without such a classification, what is accepted into Fedora Extras
and when?
Fedora Core has an early development stream and multiple test releases.
Some of this will likely be discussed at FUDCon. But currently, once a
newly added package is added to pre-extras, it's included by
definition, and we must deal with the wreckage if there are bug
reports and/or complaints.
Debian have this "feature" I am not convinced it's very
useful.
That's quite a different one.
12:19 p.m.
Le lundi 24 janvier 2005 à 18:45 +0100, Michael Schwendt a écrit :
(...)
Sorry that you disagree, but as someone who has reviewed and approved
several hundreds of packages at fedora.us, it is my opinion that the
classification (at least the split into stable+testing) has been
beneficial.
I am agree with stable+testing (or stable+rawhide).
But testing for testing propose _only_.
Mplayer is in "unstable" since many months in livna. Doesn't seems it's
for testing only.
Since many people use mplayer, many people have "unstable" in their
yum.conf.
The situation is not the same with FC/Rawhide and update/update_testing.
A very few people use Rawhide or update_testing.
> Debian have this "feature" I am not convinced it's very useful.
That's quite a different one.
Right.
12:28 p.m.
On Mon, 24 Jan 2005 19:19:26 +0100, Féliciano Matias wrote:
Le lundi 24 janvier 2005 à 18:45 +0100, Michael Schwendt a écrit :
> (...)
> Sorry that you disagree, but as someone who has reviewed and approved
> several hundreds of packages at fedora.us, it is my opinion that the
> classification (at least the split into stable+testing) has been
> beneficial.
I am agree with stable+testing (or stable+rawhide).
But testing for testing propose _only_.
Mplayer is in "unstable" since many months in livna. Doesn't seems
it's
for testing only.
Actually, the scheme at rpm.livna.org is a revised one.
Do you have any comments on the known issues why the packages stay in
"testing"?
There are a couple of packages which cannot be moved because they
cause regression and/or break other packages in "stable".
Since many people use mplayer, many people have "unstable"
in their
yum.conf.
The key point is they are free to enable these optional upgrades which
may not be as trouble-free as stuff in "stable". Those who are happy
with the last "stable" release would not like if they were forced to
install less stable releases or no mplayer at all.
The situation is not the same with FC/Rawhide and
update/update_testing.
A very few people use Rawhide or update_testing.
The developers do. And Rawhide is developed long enough to stabilize
for a first test release.
12:33 p.m.
Am Montag, den 24.01.2005, 19:19 +0100 schrieb Féliciano Matias:
Le lundi 24 janvier 2005 à 18:45 +0100, Michael Schwendt a écrit :
> (...)
> Sorry that you disagree, but as someone who has reviewed and approved
> several hundreds of packages at fedora.us, it is my opinion that the
> classification (at least the split into stable+testing) has been
> beneficial.
I am agree with stable+testing (or stable+rawhide).
But testing for testing propose _only_.
Mplayer is in "unstable" since many months in livna. Doesn't seems
it's
for testing only.
Dependency problem cause of livna bug 147. Any help to track this down
is appreciated. I did a short look but did not find anything yet.
CU
thl
--
Thorsten Leemhuis <fedora(a)leemhuis.info>
1:09 p.m.
Le lundi 24 janvier 2005 à 19:33 +0100, Thorsten Leemhuis a écrit :
Am Montag, den 24.01.2005, 19:19 +0100 schrieb Féliciano Matias:
(...)
> Mplayer is in "unstable" since many months in livna. Doesn't seems
it's
> for testing only.
Dependency problem cause of livna bug 147.
It's a bug. mplayer is a stable package with one bug (faad2).
Fedora Core have many packages like this one.
8:43 a.m.
On Mon, 24 Jan 2005 08:37:04 +0100, Ralf Corsepius <rc040203(a)freenet.de> wrote:
IMO, if you want to remove joe from Core, you should be consequent
and
remove vi, emacs, xemacs, etc. too and let only ship one single, small
and statically linked ascii text-editor remain in Core, may-be nano.
Otherwise I would recommend to remove nano, because I don't see any
reason why it should be integrated into Core.
There is value in having one ascii editor in Core when doing system
troubleshooting. Bugs still happen.. misconfigurations still
happen(more than bugs) and when you are trying to walk someone through
troubleshooting or workarounds in a mailinglist, forum, or irc... it
can be much simplier to have them use an ascii editor to make
corrections to system configuration text files and sometimes necessary
if there is a misconfiguration that prevents X from starting.
-jef
10:07 a.m.
On Jan 24, 2005, Peter Jones <pjones(a)redhat.com> wrote:
The old way of thinking about this has got to go. _Moving_ something
to
Extras is not the same thing as removing it from the distro.
Then where's the Extras rawhide tree? Are we going to have Extras
ISOs rolled out along with the test releases? Without this, Extras
just won't get as much testing because they're not going to work with
rawhide or test releases. And for people who depend on packages from
Extras, this means they're less likely to run the test releases or
track rawhide, which means less testing.
Unless Extras is really part of the distro infrastructure, instead of
a dump of packages people don't want in the core distro, the quality
of the distro as a whole is going to suffer.
We have got to stop thinking of moving something to Extras as
removing
it from the distro. Core is not the distro, it is merely a part of the
distro. Extras is another part.
+1
I really hope we're going to see FC4 Extras test1 CD go out on the
same day as FC4test1, and even have snapshots of them a few days
before to sanity-check before the actual test release.
--
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}
11:52 a.m.
On Mon, 2005-01-24 at 14:07 -0200, Alexandre Oliva wrote:
On Jan 24, 2005, Peter Jones <pjones(a)redhat.com> wrote:
> The old way of thinking about this has got to go. _Moving_ something to
> Extras is not the same thing as removing it from the distro.
Then where's the Extras rawhide tree? Are we going to have Extras
ISOs rolled out along with the test releases? Without this, Extras
just won't get as much testing because they're not going to work with
rawhide or test releases. And for people who depend on packages from
Extras, this means they're less likely to run the test releases or
track rawhide, which means less testing.
Unless Extras is really part of the distro infrastructure, instead of
a dump of packages people don't want in the core distro, the quality
of the distro as a whole is going to suffer.
Yes, this is absolutely true. We have to make it part of the same
thing, not just call it part of the same thing.
> We have got to stop thinking of moving something to Extras as
removing
> it from the distro. Core is not the distro, it is merely a part of the
> distro. Extras is another part.
+1
I really hope we're going to see FC4 Extras test1 CD go out on the
same day as FC4test1, and even have snapshots of them a few days
before to sanity-check before the actual test release.
Agreed.
--
Peter
When privacy is outlawed only outlaws will have privacy.
-- Zimmermann
11:07 p.m.
On Mon, 2005-01-24 at 14:07 -0200, Alexandre Oliva wrote:
> The old way of thinking about this has got to go. _Moving_
something to
> Extras is not the same thing as removing it from the distro.
Then where's the Extras rawhide tree? Are we going to have Extras
We haven't gotten around to deciding if Extras should be either a
rolling release, or branched off based on how we release Core. As to a
Rawhide tree, I don't think we've had the chance to think that far, but
we should duly note this down when it comes to discussing about Extras
ISOs rolled out along with the test releases? Without this, Extras
There's been thought about this, but no consensus. Let me say this is to
be added to the agenda for discussions
just won't get as much testing because they're not going to
work with
rawhide or test releases. And for people who depend on packages from
Extras, this means they're less likely to run the test releases or
track rawhide, which means less testing.
Agreed, you bring up good points
Unless Extras is really part of the distro infrastructure, instead
of
a dump of packages people don't want in the core distro, the quality
of the distro as a whole is going to suffer.
The plan is to make it part of the distro infrastructure, rest assured
(as per the terminology)
I really hope we're going to see FC4 Extras test1 CD go out on
the
same day as FC4test1, and even have snapshots of them a few days
before to sanity-check before the actual test release.
A +1 to this, but as reality hits, I don't think this is going to happen
in time. But miracles do happen sometimes ;-)
So here's hoping there's mighty discussion at FUDCon and we actually
have a good outcome from it all, and move forward from there
--
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
3:35 p.m.
On Sat, Jan 22, 2005 at 12:01:30PM -0500, Alan Cox wrote:
On Sat, Jan 22, 2005 at 05:16:30AM +0100, Féliciano Matias wrote:
> Move to Fedora Extra :
> dosfstools
> Lynx (or elinks)
lynx is needed for mutt to do html reading on text logins. Its also fairly
important for accessibility for some users. Elinks I wouldn't worry about
I prefer to use elinks on mutt:
text/html; links -dump -dump-charset iso-8859-1 -default-mime-type
text/html %s; copiousoutput;
Regards,
Luciano Rocha
--
2/16
10:30 a.m.
Le vendredi 21 janvier 2005 à 18:58 -0500, Bill Nottingham a écrit :
Removed and orphaned:
asp2php - does not show any history of usage, not really a core package
Suggested for removal:
(...)
Opinions?
Remove rpmdb.
move experimental gcc (gcc4 in FC3 for example) to Fedora Extra.
10:45 a.m.
Féliciano Matias wrote:
Remove rpmdb.
move experimental gcc (gcc4 in FC3 for example) to Fedora Extra.
You're kidding, right? Where is your smiley?
I haven't used anything but gcc4 for the last six months. It catches
more bugs that gcc3.
It would make more sense, IMO, to make gcc4 the primary compiler and to
deprecate gcc3.
Or just leave both around. Its not a disk hog like some other packages.
John
10:59 a.m.
On Sat, 2005-01-22 at 11:45 -0500, John Ellson wrote:
Féliciano Matias wrote:
>
>
>Remove rpmdb.
>move experimental gcc (gcc4 in FC3 for example) to Fedora Extra.
>
>
You're kidding, right? Where is your smiley?
I haven't used anything but gcc4 for the last six months. It catches
more bugs that gcc3.
So? That has nothing to do with whether a package is applicable to
being in Core or not. You *can* use gcc4 if it's in Extras, you
know. ;-)
It would make more sense, IMO, to make gcc4 the primary compiler and to
deprecate gcc3.
Right... except that gcc 4.0 is not yet released and is a
beta/experimental compiler. The last time Red Hat made an experimental
compiler the default they caused a metric ton of hell for everyone...
Or just leave both around. Its not a disk hog like some other
packages.
I don't think being a "disk hog" is the criteria here, either. It's
simple - either it's a core package required for the basic functionality
Fedora intends to deliver (i.e., basic server, basic development box,
usable desktop, whatever) or it's something that is an _extra_. gcc4 is
by its definition an extra, since its not the default and not even
_installed_ by default, and it is in no way required for any use case
that Fedora has that isn't solved by another package already in Core
(gcc3), so it should thus be in Extras.
That's what Extras is for - extras.
Even if cutting out gcc4 only saves a few megabytes, cutting out all the
packages in the same boat as gcc4 might just cut Fedora Core down to two
CDs, and maybe someday down to one. And it's not like you can't just
get some Extras ISOs.
Fedora really does need the ability to install off Extras CDs during
install time, though. It should be seemless - other than telling the
installer which CDs you have, the package selection process should
completely hide which ISO which package is on.
John
1:46 p.m.
On Sat, 2005-01-22 at 11:59 -0500, Sean Middleditch wrote:
[snip]
Right... except that gcc 4.0 is not yet released and is a
beta/experimental compiler. The last time Red Hat made an experimental
compiler the default they caused a metric ton of hell for everyone...
No doubt the result of the metric two tons of FUD that was circulating
about that specific decision. The whole controversy (particularly the
statement from the gcc team) was kind of ironic given that a good number
of gcc developers were Red Hat employees due to their acquisition of
Cygnus.
Even if cutting out gcc4 only saves a few megabytes, cutting out all
the
packages in the same boat as gcc4 might just cut Fedora Core down to two
CDs, and maybe someday down to one.
Awe, but I *like* doing a full install from DVD and seeing 7GB used
when I'm done. ;-)
Fedora really does need the ability to install off Extras CDs during
install time, though. It should be seemless - other than telling the
installer which CDs you have, the package selection process should
completely hide which ISO which package is on.
I second that. If that happens, I don't care what's in Core and
what's in Extras, personally. Actually, I'll bet a good part of what's
needed is already in firstboot. How about just moving it to anaconda?
--
-Paul Iadonisi
Senior System Administrator
Red Hat Certified Engineer / Local Linux Lobbyist
Ever see a penguin fly? -- Try Linux.
GPL all the way: Sell services, don't lease secrets
11:09 a.m.
Le samedi 22 janvier 2005 à 11:45 -0500, John Ellson a écrit :
Féliciano Matias wrote:
>
>
>Remove rpmdb.
>move experimental gcc (gcc4 in FC3 for example) to Fedora Extra.
>
>
You're kidding, right? Where is your smiley?
I haven't used anything but gcc4 for the last six months. It catches
more bugs that gcc3.
I don't say gcc4 is a bad compiler.
I said that experimental stuff dedicated to developer should be in
Fedora Extra. There are more users than developers.
Jeremy Katz pointed out that gcc4 is already needed by some java stuff
in FC3.
So gcc4 is not only an experimental compiler (a "toy" for for some
developers ; thanks for improving GNU/Linux) and its right place is
Fedora Core (for FC3).
10:53 a.m.
On Sat, 2005-01-22 at 17:30 +0100, Féliciano Matias wrote:
Remove rpmdb.
One of the gating factors on this is writing something to use the rpm
metadata to provide the same information. It shouldn't be hard, just
will take some time.
move experimental gcc (gcc4 in FC3 for example) to Fedora Extra.
Unfortunately, a lot of the java stuff right now is depending on gcc4
just because that's where the work is happening. Thus, tough call. On
the note of the free java stuff... gcj is really coming along
impressively in the things it can run now.
Jeremy
5:50 a.m.
Le samedi 22 janvier 2005 à 22:26 +0530, Rahul Sundaram a écrit :
Hi
. gcj is really coming along
> impressively in the things it can run now.
yes. I am impressed on the recent developments on gcj,. that reminds
me is jonas going to be included in fc4?
jonas-like package are a bitch to package because they depend on an lot
of underlying java infrastructure. There are some jonas bits in
jpackage, though I doubt there are tested enough to make in in FC yet.
You can try them and give some feedback if you want to speed things up a
bit.
Regards,
--
Nicolas Mailhot
11:21 a.m.
Le samedi 22 janvier 2005 à 11:53 -0500, Jeremy Katz a écrit :
On Sat, 2005-01-22 at 17:30 +0100, Féliciano Matias wrote:
> Remove rpmdb.
One of the gating factors on this is writing something to use the rpm
metadata to provide the same information. It shouldn't be hard, just
will take some time.
rpmdb only store Fedora Core packages.
rpmdb is huge : 37 Mo.
rpmdb help to provide a "poor resolver" to rpm. yum/apt/up2date do a
better job.
Since rpmdb is huge, perhaps rpmdb should not provide
/usr/lib/rpmdb/i386-redhat-linux/redhat/ (97 Mo) but a tool to generate
the rpmdb base (like rpmdb-fedora.spec does).
1:39 p.m.
This discussion is turning a bit absurd, imo. Just because a package is
lifted out of Core doesn't mean it will vanish from the face of the
earth. You can still install it from Extras if you need it.
More productive would be to reach a clear definition of the scope and
purpose of Core and Extras, respectively. Then the question of whether a
package belongs in Core or Extras or neither should be fairly trivial.
There seems to be a general consensus that Core should have no more than
one or two pieces of software for any given task. The Desktop sub-
project (Bluecurve) has a clear definition of how these applications are
selected: http://fedora.redhat.com/projects/desktop/defaults.html. This
checklist can quite easily be adopted for the entire Core.
Other applications/toolkits/etc that are more of niche players, or less
used, can and should live in Extras. Question that are currently
unanswered about Extras include:
- Who will maintain the Extras packages? RH, the community or both?
- Will Extras be distributed in ISO form, and will it be possible to use
the Extras CD during installation?
- Will the packages in Extras be continually updated, like they were in
fedora.us, or will they move more slowly, like the RH maintained
packages in Core?
And finally, the issue of ISO content distribution: can the ISOs be
split up more intelligently, according to type of installation? For
example: for a default headless server or minimal installation, use CD
1. For a default desktop or workstation installation, use CD 1 and 2.
For a non-default graphical installations with no non-English
localization, use CD 1, 2 and 3. For localized/internationalized
installations, use all four CDs.
/Peter Backlund
2:11 p.m.
On Sat, 22 Jan 2005 20:39:26 +0100, Peter Backlund
<peter.backlund(a)home.se> wrote:
There seems to be a general consensus that Core should have no more
than
one or two pieces of software for any given task.
I'm not so sure there is a general concensous about that.... I see
people lobbying for several different usage cases but I don't see a
clear defined set of usage cases that Core is suppose to fulfill by
itself. 'General Purpose' is too vague. I think Core needs to back
up and define one or two specific usage cases and target those.. and
move out applications and technologies that do not fit into the
primary usage situations. Core right now is a compromise that suits
pretty much everyone equally badly. And while thats an admirable
feat, its doesn't give a clear guiding perspective for the future .
If there is serious interest in slimming Core down.. then a decision
has to be made to define a reference usage case or two so we can get
past personal preference and make decisions based on the design needs
of the usage case goal. If a reference usage case for Core is suppose
to be a developer oriented workspace thats going to impact the
decisions as to what is important to include. If a reference usage
case for Core is suppose to be a desktop for the average human, that's
going to impact the decisions in very different ways. If Core is
suppose to provide both.. well guess what.. Core will continue to be
4+ CD images.
You can't have a small footprint and have ultimate flexibility.
Frankly I think the community has a whole is better served if Core
defines its primary usage case to be average human being's desktop and
push as much of the developer and highly technically oriented tools to
Extras. I personally use emacs and tetex more than openoffice.org...
but i would much rather have Emacs and tetex maintained in extras than
move openoffice.org out. I think a primary usage case that places a
premium on out-of-the-box ease for a developer or 'power user' is
somewhat backwards. I certaintly don't NEED emacs and tetex to be
installed by default. I simply NEED a way to get those tools installed
from media. And the same goes with most of the non modern desktop
tools i need to write code or technical documentation. And I would say
'most' of the fedora developers know enough to get by just fine if
they had to use Extras to get developer oriented tools installed.
But even 'average human being' isn't specific enough.. i think there
needs to be some very clearly defined usage cases or personas that
Core needs to target, personas or characters that can be used as a
reference for decissions as to what applications to include paying
very close attention. Not just typical day-to-day tasks as the
persona.. I know some people inside Red Hat think in these terms and i
think it needs to be applied to Core's definition as a stand-alone OS.
-jef"My general rule of thumb is... if I use it on a daily basis.. its
clearly not something an average person will want and therefore it
should not be in Core"spaleta
5:08 p.m.
On Sat, 22 Jan 2005 18:30:33 -0200, Casimiro de Almeida Barreto
The best thing to do about that is to make a pol: send periodic
reports to
be filled by members of Fedora comunities and trying to measure what is
being used, by who and under what circunstancies.
Bah... i dont care about popularity.... I dont care one little bit
about it. Relying on a measure of current popularity is going to
entrench the status quo in terms of user demographics and
technologies.. not a particularly good idea for a distro that is
suppose to be pushing new promising technology in quickly. And polls
of this nature are subject to extreme 'sweaky wheel' bias.
-jef
5:23 p.m.
On Sat, 22 Jan 2005 18:30:33 -0200, Casimiro de Almeida Barreto
The best thing to do about that is to make a pol: send periodic
reports to
be filled by members of Fedora comunities and trying to measure what is
being used, by who and under what circunstancies.
Relying on a measure of current popularity run the risk of entrenching
the status quo in terms of user demographics and technologies.. not a
particularly good idea for a distro that is suppose to be pushing new
promising technology in quickly. And polls of this nature are subject
to extreme 'sweaky wheel' bias where a small minority who care deeply
about keeping their applications in could very well respond in a
disproportionate manner compared to people who just use default apps
and don't care enough to respond. Not sure if its worth the effort to
mount a poll that can't be used in a quantitative way.
-jef
5:38 p.m.
On Sat, Jan 22, 2005 at 06:23:45PM -0500, Jeff Spaleta wrote:
Relying on a measure of current popularity run the risk of
entrenching
the status quo in terms of user demographics and technologies.. not a
particularly good idea for a distro that is suppose to be pushing new
It also may not be productive if you don't stat the usage of the programs.
Debian data for example does this and it tells you that people install
KDE then don't use it (but don't delete it). No suprise there but its
important to know.
5:54 p.m.
On Sat, 22 Jan 2005 18:38:56 -0500, Alan Cox <alan(a)redhat.com> wrote:
It also may not be productive if you don't stat the usage of the
programs.
Debian data for example does this and it tells you that people install
KDE then don't use it (but don't delete it). No suprise there but its
important to know.
On a tangent to this... whats the easiest way to get a feel of which
packages I'm not using on my fedora install? Is there anytihng more
clever than doing an exhaustive check of atimes on all the files owned
by rpm packages and comparing that to the package install time?
-jef
6:25 p.m.
Jeff Spaleta wrote:
On a tangent to this... whats the easiest way to get a feel of which
packages I'm not using on my fedora install? Is there anytihng more
clever than doing an exhaustive check of atimes on all the files owned
by rpm packages and comparing that to the package install time?
After I do a fresh install, I usually just go through the "rpm -qa"
list and start trying "rpm -e" on stuff that I believe I don't use,
and see when I get a dependency on something that I know I *do* use.
Which is distressingly often. There is just an amazing amount of
dependency clutter in there.
For example: I don't use Windows, ever. This means I don't use Samba.
But I can't uninstall it, because Nautilus depends on it. Now, I don't
use Nautilus either, but I can't just uninstall *that*, because
control-center depends on it, which I *do* use.
Likewise, I don't own a printer and haven't in years, but I often find
myself unable to delete the zillions of printer drivers without also
deleting Ghostscript and half of Gnome or something.
If space is tight, the first thing I do is nuke everything except en_US
under /usr/share/locale/ and /usr/lib/locale/ -- since I don't happen to
speak 113 different languages, that's more than 320MB of pure waste.
Blowing away /usr/share/doc/ is also helpful; it's huge, and every file
in there is Googlable.
--
Jamie Zawinski jwz(a)jwz.org http://www.jwz.org/
jwz(a)dnalounge.com http://www.dnalounge.com/
http://jwz.livejournal.com/
8:39 p.m.
Jamie Zawinski wrote:
Jeff Spaleta wrote:
>On a tangent to this... whats the easiest way to get a feel of which
>packages I'm not using on my fedora install? Is there anytihng more
>clever than doing an exhaustive check of atimes on all the files owned
>by rpm packages and comparing that to the package install time?
>
>
After I do a fresh install, I usually just go through the "rpm -qa"
list and start trying "rpm -e" on stuff that I believe I don't use,
and see when I get a dependency on something that I know I *do* use.
Try "rpm -qa --last", the older packages are often unused.
Which is distressingly often. There is just an amazing amount of
dependency clutter in there.
"dependency clutter" presumes that dependencies are arbitrarily designed to
decrease the quality of your life.
That is not the case.
Instead ...
For example: I don't use Windows, ever. This means I don't
use Samba.
But I can't uninstall it, because Nautilus depends on it. Now, I don't
use Nautilus either, but I can't just uninstall *that*, because
control-center depends on it, which I *do* use.
... nautilus "needs" samba much likes it needs just about every other
bleeping library
in FC4. Why? Because users want "features", and features requires
implementations,
usually in libraries, which use sonames, which are copied into package
dependencies.
This situation is unlikely to change as long as users want "features", duh.
However, dependencies are the least of your problems. As long as
nautilus links
libraries that link libraries that link libraraies that need samba, then
one will not
be able to achieve joy of a full "featured" nautilus that executes
unless the
necessary libraries are, indeed, present and installed.
Blaming dependencies form libraries is like blaming Kerry for Iraq.
Likewise, I don't own a printer and haven't in years, but I
often find
myself unable to delete the zillions of printer drivers without also
deleting Ghostscript and half of Gnome or something.
So change how ghostscript is packaged, splitting out each individual printer
driver into a separate package, leaving a pristine ghostscript that
floats your boat.
If space is tight, the first thing I do is nuke everything except
en_US
under /usr/share/locale/ and /usr/lib/locale/ -- since I don't happen to
speak 113 different languages, that's more than 320MB of pure waste.
If space is tight, then you're cheap ;-) Seriously, diska *are* cheap.
And there
is already a mechanism to install only requested locales, feel free to
configure
to limit locales to *only* en_US if your boat is sinking because of locale
baggage.
Blowing away /usr/share/doc/ is also helpful; it's huge, and every
file
in there is Googlable.
Try --excludedocs, been in rpm for years. Seriously, /usr/share/doc
ain't the problem,
look around a bit on your file system with "du -s".
73 de Jeff
9:03 p.m.
Jeff Johnson wrote:
... nautilus "needs" samba much likes it needs just about every other
bleeping library in FC4. Why? Because users want "features", and
features requires implementations, usually in libraries, which use
sonames, which are copied into package dependencies.
If you think that the fact that Nautilus has a lot of "features" means
that it's necessary for it to cause the entire desktop as a single
unsplittable ball of mud, well, you have been misinformed.
So change how ghostscript is packaged, splitting out each individual
printer driver into a separate package, leaving a pristine ghostscript
that floats your boat.
Hey, guess what! I don't maintain Ghostscript or work for Red Hat!
Other people on this list have the ability to fix this crap, not me.
If space is tight, then you're cheap ;-)
Ok smartass, now why don't you explain to me how I'm "cheap" because I
don't have the time or inclination to back up, repartition, and restore
my machines' drives every time I upgrade the OSes because someone with
your "disk space doesn't matter" attitude decided that it was ok for a
default install to go from a /usr that takes ~400MB to >2GB in just two
years.
Seriously, diska *are* cheap.
Seriously, you *are* missing the point.
And there is already a mechanism to install only requested locales,
feel free to configure to limit locales to *only* en_US if your boat
is sinking because of locale baggage.
What binary rpm installation does that? Oh, I'm sorry, you must have
been under the impression that I was compiling all my packages from
source, since everyone does that.
Try --excludedocs, been in rpm for years.
I must have overlooked the Anaconda checkbox that turns that on.
And the "yum update" option, too.
look around a bit on your file system with "du -s".
GOLLY I NEVER THOUGHT OF THAT.
--
Jamie Zawinski jwz(a)jwz.org http://www.jwz.org/
jwz(a)dnalounge.com http://www.dnalounge.com/
http://jwz.livejournal.com/
9:28 p.m.
Jamie Zawinski wrote:
Jeff Johnson wrote:
>... nautilus "needs" samba much likes it needs just about every other
>bleeping library in FC4. Why? Because users want "features", and
>features requires implementations, usually in libraries, which use
>sonames, which are copied into package dependencies.
>
>
If you think that the fact that Nautilus has a lot of "features" means
that it's necessary for it to cause the entire desktop as a single
unsplittable ball of mud, well, you have been misinformed.
By George, I think he's got it! The point is that dependencies are not
the problem,
bloat is.
>So change how ghostscript is packaged, splitting out each individual
>printer driver into a separate package, leaving a pristine ghostscript
>that floats your boat.
>
>
Hey, guess what! I don't maintain Ghostscript or work for Red Hat!
Other people on this list have the ability to fix this crap, not me.
Well I have maintained ghostscript for Red Hat, and splitting up the drivers
into single packages so that users who wish to use ghostscript without
printer drivers just ain't worth the trouble. How much space is saved?
And how many additional packages need to be added, one per driver,
to support the illusion of choice?
Do the math, it's not worth the trouble. There are far bigger problems
that need solving than ghostscript drivers.
>If space is tight, then you're cheap ;-)
>
>
Ok smartass, now why don't you explain to me how I'm "cheap" because I
don't have the time or inclination to back up, repartition, and restore
my machines' drives every time I upgrade the OSes because someone with
your "disk space doesn't matter" attitude decided that it was ok for a
default install to go from a /usr that takes ~400MB to >2GB in just two
years.
I, too was astonished at the amount of bloat. And the actual sum is
closer to 4 GB, then 2 Gb
for an "everything" install. And the bloat happened longer than 2 years ago.
Again because users wish "features", like 4 or 5 copies of automake
(I've lost count),
and 6+ copies of Berkely DB. And 6+ shells, and as many text editors as
exist, and ...
>Seriously, diska *are* cheap.
>
>
Seriously, you *are* missing the point.
What was the point I'm missing again?
>And there is already a mechanism to install only requested locales,
>feel free to configure to limit locales to *only* en_US if your boat
>is sinking because of locale baggage.
>
>
What binary rpm installation does that? Oh, I'm sorry, you must have
been under the impression that I was compiling all my packages from
source, since everyone does that.
No, choosing locales is an install option that applies to binary options
that is anaconda
selectable, and globally configurable. And all rpm installations since
like RHL 7.2 have
had that functionality.
>Try --excludedocs, been in rpm for years.
>
>
I must have overlooked the Anaconda checkbox that turns that on.
And the "yum update" option, too.
So make an RFE. The mechanism exists even if anaconda and yum choose not
to use
--excludedocs. The mechanism is also globally configurable, put
%_netsharedpath /usr/share/doc
in /etc/rpm/macros.
Or keeep bitching about the energy and effort that *YOU* need to go
through to
tune *YOUR* system to *YOUR* custom tatstes, perhaps *YOU* will be
heard, and yum and anaconda will provide *YOU* a special radio button
that customizes exactly to *YOUR* taste.
>look around a bit on your file system with "du -s".
>
>
GOLLY I NEVER THOUGHT OF THAT.
Well keep practicing, perhaps you'll figger it out some day.
73 de Jeff
10:31 p.m.
Jeff Johnson <n3npq(a)nc.rr.com> writes:
>If you think that the fact that Nautilus has a lot of
"features" means
>that it's necessary for it to cause the entire desktop as a single
>unsplittable ball of mud, well, you have been misinformed.
By George, I think he's got it! The point is that dependencies are not
the problem,
The gnupg -> (perl,openldap) deps *are* a problem, because they are not
needed for the gnupg core functionality but only for two extra programs,
which are unused on most systems.
bloat is.
Yes, the stupid kernel packaging which brings 30 MB of bloat into / is a
problem also. But nevertheless, the deps should be cut. A candidate would
be 'pam' which brings 'glib2' in, or all the packages with 'Requires:
kernel>=2.6' which should be either removed or rewritten to 'Conflicts:
kernel<2.6'.
No, choosing locales is an install option that applies to binary
options that is anaconda selectable,
I might be wrong (I do not have time to verify it now) but afair, on my
last FC3 installation, the language selection in anaconda had no influence
on %_install_langs but sets some value in /etc/sysconfig/i18n only.
>>Try --excludedocs, been in rpm for years.
>
>I must have overlooked the Anaconda checkbox that turns that on. And
>the "yum update" option, too.
So make an RFE.
Has probably only a small chance of success. 'anaconda' will follow more
and more the Gnome UI guidelines so that there is no room for useful
features. Existing ones like package selection or detailed progress
reports were removed already.
The mechanism exists even if anaconda and yum choose not to use
--excludedocs. The mechanism is also globally configurable, put
%_netsharedpath /usr/share/doc
mmmh... %_netsharedpath... we had a lot of fruitless discussions about
this so I wonder that you mention it here ;)
It has serious implementation flaws (infection of parent paths; bug
#52725 lasts for >3 years in bugzilla) and there does not exist a
mechanisms to test it in %scriptlets (which causes problems e.g. in
all the java packages).
Using %_netsharedpath to disable installation of certain files is not a
good idea. E.g. files in /usr/share/doc are required by cups for its
web-frontend. %_netsharedpath is for situations where the files exist
but are managed externally.
in /etc/rpm/macros.
anaconda does not honor any previous rpm setting. Partially, this is
caused by rpm which makes it really difficultly to override paths of its
configuration.
Enrico
11:07 p.m.
Enrico Scholz wrote:
Jeff Johnson <n3npq(a)nc.rr.com> writes:
>>If you think that the fact that Nautilus has a lot of "features" means
>>that it's necessary for it to cause the entire desktop as a single
>>unsplittable ball of mud, well, you have been misinformed.
>>
>>
>By George, I think he's got it! The point is that dependencies are not
>the problem,
>
>
The gnupg -> (perl,openldap) deps *are* a problem, because they are not
needed for the gnupg core functionality but only for two extra programs,
which are unused on most systems.
>bloat is.
>
>
Yes, the stupid kernel packaging which brings 30 MB of bloat into / is a
problem also. But nevertheless, the deps should be cut. A candidate would
be 'pam' which brings 'glib2' in, or all the packages with 'Requires:
kernel>=2.6' which should be either removed or rewritten to 'Conflicts:
kernel<2.6'.
Perhaps. The rationale for preferring Requires: rather than Conflicts:
is that
depsolvers have a
Will an upgrade "fix" a dependency problem?
but do not have a similar, widely deployed, policy for Conflicts: afaik.
Well, apt does, and perhaps smartpm, but let's not go there ...
>No, choosing locales is an install option that applies to binary
>options that is anaconda selectable,
>
>
I might be wrong (I do not have time to verify it now) but afair, on my
last FC3 installation, the language selection in anaconda had no influence
on %_install_langs but sets some value in /etc/sysconfig/i18n only.
If true, then it's a bug in anaconda, which does permit selection of
desired locales,
and has attempted to limit the number of installed locales in the past.
>>>Try --excludedocs, been in rpm for years.
>>>
>>>
>>I must have overlooked the Anaconda checkbox that turns that on. And
>>the "yum update" option, too.
>>
>>
>So make an RFE.
>
>
Has probably only a small chance of success. 'anaconda' will follow more
and more the Gnome UI guidelines so that there is no room for useful
features. Existing ones like package selection or detailed progress
reports were removed already.
Predciting the future without attempting an RFE is pointless blather.
Not that you
haven't made many reasonable RFE's over the years ...
>The mechanism exists even if anaconda and yum choose not to use
>--excludedocs. The mechanism is also globally configurable, put
> %_netsharedpath /usr/share/doc
>
>
mmmh... %_netsharedpath... we had a lot of fruitless discussions about
this so I wonder that you mention it here ;)
It has serious implementation flaws (infection of parent paths; bug
#52725 lasts for >3 years in bugzilla) and there does not exist a
mechanisms to test it in %scriptlets (which causes problems e.g. in
all the java packages).
Using %_netsharedpath to disable installation of certain files is not a
good idea. E.g. files in /usr/share/doc are required by cups for its
web-frontend. %_netsharedpath is for situations where the files exist
but are managed externally.
Yep, all well known. %_netsharedpath is a naive mechanism.
OTOH, %_netsharedpath *will* prevent /usr/share/doc from being
populated, and
the "infection" you speak of, for an empty /usr/share/doc directory, is
irrelevant on this thread.
>in /etc/rpm/macros.
>
>
anaconda does not honor any previous rpm setting. Partially, this is
caused by rpm which makes it really difficultly to override paths of its
configuration.
Actually, I suspect the problem is that anaconda may be carrying a
canned configuration
into an empty chroot that is difficult to configure. All paths in rpm
are changeable through
appropriate configuration, difficulty is in the eye of the beholder.
73 de Jeff
6:40 a.m.
Jeff Johnson <n3npq(a)nc.rr.com> writes:
>Partially, this is caused by rpm which makes it really difficultly
to
>override paths of its configuration.>
All paths in rpm are changeable through appropriate configuration,
difficulty is in the eye of the beholder.
What would be the "appropriate configuration" to change the path of
/etc/rpm/platform?
Enrico
8:23 a.m.
Enrico Scholz wrote:
Jeff Johnson <n3npq(a)nc.rr.com> writes:
>>Partially, this is caused by rpm which makes it really difficultly to
>>override paths of its configuration.>
>>
>>
>All paths in rpm are changeable through appropriate configuration,
>difficulty is in the eye of the beholder.
>
>
What would be the "appropriate configuration" to change the path of
/etc/rpm/platform?
rm -f /etc/rpm/platform and live with uname(2) lies from the kernel.
73 de Jeff
9:06 a.m.
Jeff Johnson <n3npq(a)nc.rr.com> writes:
>>All paths in rpm are changeable through appropriate
configuration,
>>difficulty is in the eye of the beholder.
>
>What would be the "appropriate configuration" to change the path of
>/etc/rpm/platform?
rm -f /etc/rpm/platform and live with uname(2) lies from the kernel.
??? How will this help for '--root' installations for i586-redhat-linux
guests on an i686-redhat-linux host?
Enrico
10:07 a.m.
Enrico Scholz wrote:
Jeff Johnson <n3npq(a)nc.rr.com> writes:
>>>All paths in rpm are changeable through appropriate configuration,
>>>difficulty is in the eye of the beholder.
>>>
>>>
>>What would be the "appropriate configuration" to change the path of
>>/etc/rpm/platform?
>>
>>
>rm -f /etc/rpm/platform and live with uname(2) lies from the kernel.
>
>
??? How will this help for '--root' installations for i586-redhat-linux
guests on an i686-redhat-linux host?
It doesn't.
And /etc/rpm/platform is not part of rpm configuration, but rather a
replacemnet
for uname(2) imho.
And yes, arch (and os) in rpm is fabulously useless, always has been.
Someday I'll be
permitted to change the crap.
But we've come quite far from the original thread, haven't we?
No matter what
%_netsharedpath /usr/share/doc
prevents installation of doco files, and is less crude than the the original
complaint that the following was needed to reclaim disk space:
cd /usr/share/doc
rm -f *
73 de Jeff
6:51 a.m.
On Sun, Jan 23, 2005 at 05:31:37AM +0100, Enrico Scholz wrote:
The gnupg -> (perl,openldap) deps *are* a problem, because they
are not
needed for the gnupg core functionality but only for two extra programs,
which are unused on most systems.
Agreed. I dislike having perl on systems I run because then people do
disgusting things like use it.
problem also. But nevertheless, the deps should be cut. A candidate
would
be 'pam' which brings 'glib2' in, or all the packages with 'Requires:
glib2 is used by a lot of stuff nowdays because it provides stuff like
real string libraries for C - its not too huge either
kernel>=2.6' which should be either removed or rewritten to
'Conflicts:
kernel<2.6'.
Perhaps
I might be wrong (I do not have time to verify it now) but afair, on
my
last FC3 installation, the language selection in anaconda had no influence
on %_install_langs but sets some value in /etc/sysconfig/i18n only.
Correct nowdays. The big problem there is openoffice though
and more the Gnome UI guidelines so that there is no room for useful
features. Existing ones like package selection or detailed progress
reports were removed already.
kickstart
Alan
--
"a complex, complicated design for some facility in a software or hardware
product is usually not an indication of great skill and maturity on the part
of the designer. Rather, it is typically evidence of lack of maturity, lack
of insight, lack of understanding of the costs of complexity, and failure to
see the problem in its larger context." -- Dan Murphy
9:41 a.m.
> I might be wrong (I do not have time to verify it now) but
afair, on my
> last FC3 installation, the language selection in anaconda had no influence
> on %_install_langs but sets some value in /etc/sysconfig/i18n only.
Correct nowdays. The big problem there is openoffice though
Isn't that supposed to be resolved for fc4? Splitting OpenOffice-i18n
into several different subpackages?
Why is this so hard, anyway?
4:52 a.m.
On Sun, 2005-01-23 at 05:31 +0100, Enrico Scholz wrote:
Yes, the stupid kernel packaging which brings 30 MB of bloat into /
is a
problem also. But nevertheless, the deps should be cut. A candidate would
be 'pam' which brings 'glib2' in, or all the packages with
'Requires:
kernel>=2.6' which should be either removed or rewritten to 'Conflicts:
kernel<2.6'.
The problem is pam_console (and maybe others) modules (which are by
default configured to be used) require glib2. And I don't see any
possibility to make the pam_console optional. So you can tune your
minimum install so the pam_console is removed from all /etc/pam.d/...
configs and then you can remove glib2. Or you can write a patch for all
pam modules in redhat which use glib2 which replace the functionality
provided by glib2 by another means and if it's good it will be applied.
But I won't write it as I have many more useful things to do.
--
Tomas Mraz <tmraz(a)redhat.com>
5:54 a.m.
On Mon, Jan 24, 2005 at 11:52:24AM +0100, Tomas Mraz wrote:
On Sun, 2005-01-23 at 05:31 +0100, Enrico Scholz wrote:
> Yes, the stupid kernel packaging which brings 30 MB of bloat into / is a
> problem also. But nevertheless, the deps should be cut. A candidate would
> be 'pam' which brings 'glib2' in, or all the packages with
'Requires:
> kernel>=2.6' which should be either removed or rewritten to 'Conflicts:
> kernel<2.6'.
For the kernel requires you should file bz requests, glib2 looks small
enough to not worry about it IMNSHO. (Just like we don't make pam optional
or similar things. ;-)
greetings,
Florian La Roche
The problem is pam_console (and maybe others) modules (which are by
default configured to be used) require glib2. And I don't see any
possibility to make the pam_console optional. So you can tune your
minimum install so the pam_console is removed from all /etc/pam.d/...
configs and then you can remove glib2. Or you can write a patch for all
pam modules in redhat which use glib2 which replace the functionality
provided by glib2 by another means and if it's good it will be applied.
But I won't write it as I have many more useful things to do.
--
Tomas Mraz <tmraz(a)redhat.com>
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
11:57 a.m.
On Mon, 2005-01-24 at 11:52 +0100, Tomas Mraz wrote:
The problem is pam_console (and maybe others) modules (which are by
default configured to be used) require glib2. And I don't see any
possibility to make the pam_console optional. So you can tune your
minimum install so the pam_console is removed from all /etc/pam.d/...
configs and then you can remove glib2. Or you can write a patch for all
pam modules in redhat which use glib2 which replace the functionality
provided by glib2 by another means and if it's good it will be applied.
But I won't write it as I have many more useful things to do.
So does everyone else - that's why they use a working, tested, widely-
available
utility library instead of writing their own string and hash table
classes
in every single package.
Among other things, it's near impossible to write a properly
internationalized app without unicode utilities as in GLib.
Havoc
1:36 a.m.
On Mon, 2005-01-24 at 12:57 -0500, Havoc Pennington wrote:
On Mon, 2005-01-24 at 11:52 +0100, Tomas Mraz wrote:
>
> The problem is pam_console (and maybe others) modules (which are by
> default configured to be used) require glib2. And I don't see any
> possibility to make the pam_console optional. So you can tune your
> minimum install so the pam_console is removed from all /etc/pam.d/...
> configs and then you can remove glib2. Or you can write a patch for all
> pam modules in redhat which use glib2 which replace the functionality
> provided by glib2 by another means and if it's good it will be applied.
> But I won't write it as I have many more useful things to do.
So does everyone else - that's why they use a working, tested, widely-
available
utility library instead of writing their own string and hash table
classes
in every single package.
Of course I agree with you that it's generaly a good
idea to use glib2
instead of writing own string and hash table classes, but as glib2 isn't
much used in PAM, it could be replaced. I didn't say that I would like
to replace it just if someone wrote a patch which replaces it I would
look at it and maybe applied it.
--
Tomas Mraz <tmraz(a)redhat.com>
10:16 p.m.
Once upon a time, Jeff Johnson <n3npq(a)nc.rr.com> said:
... nautilus "needs" samba much likes it needs just about
every other
bleeping library
in FC4. Why? Because users want "features", and features requires
implementations,
usually in libraries, which use sonames, which are copied into package
dependencies.
nautilus has an explicit dependency in the spec file on gnome-vfs2-smb.
It does not have any apparent dependency on libsmb.so that is provided
by gnome-vfs2-smb (nothing seems to have such a dependency). If I don't
have any need to browse Windows networks, why do I need the software
installed?
Features are great; _required_ features are not.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
10:32 p.m.
Chris Adams wrote:
Once upon a time, Jeff Johnson <n3npq(a)nc.rr.com> said:
>... nautilus "needs" samba much likes it needs just about every other
>bleeping library
>in FC4. Why? Because users want "features", and features requires
>implementations,
>usually in libraries, which use sonames, which are copied into package
>dependencies.
>
>
nautilus has an explicit dependency in the spec file on gnome-vfs2-smb.
It does not have any apparent dependency on libsmb.so that is provided
by gnome-vfs2-smb (nothing seems to have such a dependency). If I don't
have any need to browse Windows networks, why do I need the software
installed?
Features are great; _required_ features are not.
rpm -q --changelog nautilus
...
* Thu Aug 26 2004 Alexander Larsson <alexl(a)redhat.com> - 2.7.4-3
- Added requires eject
- Depend on gnome-vfs2-smb instead of -extras
RFE in bugzilla is far more effective mechanism for change than
fedora-devel.
73 de Jeff
12:30 a.m.
On Sat, 2005-01-22 at 22:16 -0600, Chris Adams wrote:
nautilus has an explicit dependency in the spec file on gnome-vfs2-smb.
It does not have any apparent dependency on libsmb.so that is provided
by gnome-vfs2-smb (nothing seems to have such a dependency). If I don't
have any need to browse Windows networks, why do I need the software
installed?
libsmb.so is dlopen'd, so no ldd dependency.
Features are great; _required_ features are not.
The reason for a Requires here (and in similar cases)
is to suck in gnome-vfs2-smb when anaconda upgrades
a system.
Comes up with some package in most releases, and there
are a fair number of Requires: that exist purely for
that reason.
Havoc
5:16 a.m.
Havoc Pennington wrote:
On Sat, 2005-01-22 at 22:16 -0600, Chris Adams wrote:
>nautilus has an explicit dependency in the spec file on gnome-vfs2-smb.
>It does not have any apparent dependency on libsmb.so that is provided
>by gnome-vfs2-smb (nothing seems to have such a dependency). If I don't
>have any need to browse Windows networks, why do I need the software
>installed?
>
>
libsmb.so is dlopen'd, so no ldd dependency.
And so the problem really is too many dependencies, or -- alternatively
expressed -- too few sonames.
Perhaps
Requires: libsmbclient.so.0
is perhaps a more obvious statement of the dependency.
Not that the mode of expression really matters, nautilus has way way too
many dependencies.
>Features are great; _required_ features are not.
>
>
The reason for a Requires here (and in similar cases)
is to suck in gnome-vfs2-smb when anaconda upgrades
a system.
Yep.
<scarcasm>
Or anaconda might, perhaps, someday, wish to actually
run nautilus at install/erase time, and so the dependency is added
as a place holder, reserving a bloat slot for future development.
</scarcasm>
Seriously, dependencies have a context, and it's highly unlikely
that the dependency is actually needed by anaconda to install
or remove nautilus. The hint to depsolvers like anaconda necessary
with current implementations to discover an additional edge in
the dependency tree graph could be handled in other ways,
if nautilus were prepared to deal with the dlopen failure at
run-time.
Comes up with some package in most releases, and there
are a fair number of Requires: that exist purely for
that reason.
Yep. Existence of other examples does not imply that dlopen'd module
dependencies
necessarily have to be expressed as a Requires: however.
The current practice of using a manual Requires: to hint of an edge on
a dependency graph has the side affect of forcing packages to be installed
whose contents may never be used.
A "missingok" (or "dlopen") context marker on a Requires: would
provide
the hint of an
edge in the dependency graph to existing depsolvers, and yet mark the
context of the
dependency as "optional" in the sense that an application like nautilus
was prepared to
deal with a dlopen failure from libsmbclient.so.0 at run-time, rather
than during install/erase.
The net effect of a "missingok" (or "dlopen") context marker would be
that nautilus could
be installed without dragging in the samba sub-tree, with similar effect
for other dlopen'd
modules.
73 de Jeff
12:42 p.m.
On Sun, 2005-01-23 at 06:16 -0500, Jeff Johnson wrote:
Seriously, dependencies have a context, and it's highly unlikely
that the dependency is actually needed by anaconda to install
or remove nautilus. The hint to depsolvers like anaconda necessary
with current implementations to discover an additional edge in
the dependency tree graph could be handled in other ways,
if nautilus were prepared to deal with the dlopen failure at
run-time.
nautilus does not require the SMB backend to work, however
we do want it installed by default (even on upgrade).
If (as it does now) that means some people have to
keep it installed even though they don't want it,
then too bad; it's simply more important to get it
installed by default.
If someone fixes it so there's no tradeoff (we can
get it by default, *and* you can uninstall it),
then fantastic; of course nobody will object.
A "requires(missingok)" sounds fine to me, but
the anaconda guys are the ones whose opinion
counts.
Havoc
12:58 p.m.
Havoc Pennington wrote:
On Sun, 2005-01-23 at 06:16 -0500, Jeff Johnson wrote:
>Seriously, dependencies have a context, and it's highly unlikely
>that the dependency is actually needed by anaconda to install
>or remove nautilus. The hint to depsolvers like anaconda necessary
>with current implementations to discover an additional edge in
>the dependency tree graph could be handled in other ways,
>if nautilus were prepared to deal with the dlopen failure at
>run-time.
>
>
nautilus does not require the SMB backend to work, however
we do want it installed by default (even on upgrade).
If (as it does now) that means some people have to
keep it installed even though they don't want it,
then too bad; it's simply more important to get it
installed by default.
If someone fixes it so there's no tradeoff (we can
get it by default, *and* you can uninstall it),
then fantastic; of course nobody will object.
A "requires(missingok)" sounds fine to me, but
the anaconda guys are the ones whose opinion
counts.
The mechanism was proposed several months ago, and I'm perfectly willing
to commit rpm to a bit the dependency context bit fields that supplies a
mechanism
of "missingok" (i.e. supply hint to the depsovers, which can do whatever
they
wish semantically with the bit delivered, on return rpmlib is permitted
to blithely
ignore the dependency after delivery).
I have heard nada, zippo, nil, nothing except <shrug> from the depsolver
maintainers.
Open an RFE please, and ask for explicit sign off from the depsolver
crowd, if you
truly wish the functionality. The implementation is nothing more than
testing a bit
in 3 places and arguing whether "missingok" is the appropriate token for
the mechanism,
as the semantic is entirely opaque to rpmlib (which supplies mechanism
only).
Think: about 3 hours work in rpmlib.
73 de Jeff
5:58 p.m.
On Sun, 2005-01-23 at 13:42 -0500, Havoc Pennington wrote:
If someone fixes it so there's no tradeoff (we can
get it by default, *and* you can uninstall it),
then fantastic; of course nobody will object.
A "requires(missingok)" sounds fine to me, but
the anaconda guys are the ones whose opinion
counts.
...
And, of course, there's the ever fun part about if there's anything like
this, then _every time you do an upgrade_, you'll get the package added
back.
At which point, people complain, we turn off the use of the hint on
upgrades and we're back to step1. Around and around the mulberry bush
we go, where it stops, no one knows.
Jeremy
6:06 p.m.
Jeremy Katz wrote:
On Sun, 2005-01-23 at 13:42 -0500, Havoc Pennington wrote:
>If someone fixes it so there's no tradeoff (we can
>get it by default, *and* you can uninstall it),
>then fantastic; of course nobody will object.
>
>A "requires(missingok)" sounds fine to me, but
>the anaconda guys are the ones whose opinion
>counts.
>
>
...
And, of course, there's the ever fun part about if there's anything like
this, then _every time you do an upgrade_, you'll get the package added
back.
At which point, people complain, we turn off the use of the hint on
upgrades and we're back to step1. Around and around the mulberry bush
we go, where it stops, no one knows.
Not true.
The "missingok" mechanism fails on legacy code/packaging by reproducing
the current behavior exactly as is.
Meanwhile, new packaging for, say, nautilus which has
Requires(missingok): gnome-vfs2-smb
and a depsolver that tests RPMSENSE_MISSINGOK drop a sub-tree that
is optional.
I fail to see a mulberry bush, except in this loopy and endless fretting.
Show me the mulberries *please*.
73 de Jeff
2:02 a.m.
Meanwhile, new packaging for, say, nautilus which has
Requires(missingok): gnome-vfs2-smb
and a depsolver that tests RPMSENSE_MISSINGOK drop a sub-tree that
is optional.
I fail to see a mulberry bush, except in this loopy and endless fretting.
Show me the mulberries *please*.
user goes from package-1.0-1.0 to package-1.1-1.0 which now had a
Requires(missingok): gnome-vfs2-smp. Fine; yum (for the sake of
argument) grabs gnome-vfs2-smp as well and everything is happy.
Now the user gets annoyed by the "bloat" and removes gnome-vfs2-smp.
Still fine.
Then a security update comes out, package-1.1-1.1 and the user of course
upgrades to that. yum will *AGAIN* pull in gnome-vfs2-smp. User gets
really annoyed and considers this not-fine.
Would there be a way to version the missingok such that it's a hint to
the depsolver to only solve the dep if the old package is matching the
versioning ?
2:20 a.m.
Arjan van de Ven wrote:
>Meanwhile, new packaging for, say, nautilus which has
> Requires(missingok): gnome-vfs2-smb
>and a depsolver that tests RPMSENSE_MISSINGOK drop a sub-tree that
>is optional.
>
>I fail to see a mulberry bush, except in this loopy and endless fretting.
>
>Show me the mulberries *please*.
>
>
user goes from package-1.0-1.0 to package-1.1-1.0 which now had a
Requires(missingok): gnome-vfs2-smp. Fine; yum (for the sake of
argument) grabs gnome-vfs2-smp as well and everything is happy.
Now the user gets annoyed by the "bloat" and removes gnome-vfs2-smp.
Still fine.
Then a security update comes out, package-1.1-1.1 and the user of course
upgrades to that. yum will *AGAIN* pull in gnome-vfs2-smp. User gets
really annoyed and considers this not-fine.
Would there be a way to version the missingok such that it's a hint to
the depsolver to only solve the dep if the old package is matching the
versioning ?
The "missingok" bit is passed to yum. Yum can of course choose to treat the
"missingok" dependency as a mandatory Requires:, in which case the beahavior
is as you describe.
Or yum, and anaconda, and up2date might perhaps do something more
intelligent.
You never know, do ya?
73 de Jeff
2:50 a.m.
On Mon, Jan 24, 2005 at 09:02:15AM +0100, Arjan van de Ven wrote:
> Meanwhile, new packaging for, say, nautilus which has
> Requires(missingok): gnome-vfs2-smb
> and a depsolver that tests RPMSENSE_MISSINGOK drop a sub-tree that
> is optional.
>
> I fail to see a mulberry bush, except in this loopy and endless fretting.
>
> Show me the mulberries *please*.
user goes from package-1.0-1.0 to package-1.1-1.0 which now had a
Requires(missingok): gnome-vfs2-smp. Fine; yum (for the sake of
argument) grabs gnome-vfs2-smp as well and everything is happy.
Now the user gets annoyed by the "bloat" and removes gnome-vfs2-smp.
Still fine.
Then a security update comes out, package-1.1-1.1 and the user of course
upgrades to that. yum will *AGAIN* pull in gnome-vfs2-smp. User gets
really annoyed and considers this not-fine.
Would there be a way to version the missingok such that it's a hint to
the depsolver to only solve the dep if the old package is matching the
versioning ?
Sounds to me like we should install gnome-vfs2-smb via comps.xml to
provide it per default for new installs, but also let people de-install it.
Then the remaining item is to look at updates. I think with good error
messages and maybe some release notes this should be ok, not that much
more rpm deps can solve for this situation.
greetings,
Florian La Roche
3:17 a.m.
mån 2005-01-24 klockan 09:50 +0100 skrev Florian La Roche:
On Mon, Jan 24, 2005 at 09:02:15AM +0100, Arjan van de Ven wrote:
>
> > Meanwhile, new packaging for, say, nautilus which has
> > Requires(missingok): gnome-vfs2-smb
> > and a depsolver that tests RPMSENSE_MISSINGOK drop a sub-tree that
> > is optional.
> >
> > I fail to see a mulberry bush, except in this loopy and endless fretting.
> >
> > Show me the mulberries *please*.
>
>
> user goes from package-1.0-1.0 to package-1.1-1.0 which now had a
> Requires(missingok): gnome-vfs2-smp. Fine; yum (for the sake of
> argument) grabs gnome-vfs2-smp as well and everything is happy.
> Now the user gets annoyed by the "bloat" and removes gnome-vfs2-smp.
> Still fine.
>
> Then a security update comes out, package-1.1-1.1 and the user of course
> upgrades to that. yum will *AGAIN* pull in gnome-vfs2-smp. User gets
> really annoyed and considers this not-fine.
>
> Would there be a way to version the missingok such that it's a hint to
> the depsolver to only solve the dep if the old package is matching the
> versioning ?
>
Sounds to me like we should install gnome-vfs2-smb via comps.xml to
provide it per default for new installs, but also let people de-install it.
Then the remaining item is to look at updates. I think with good error
messages and maybe some release notes this should be ok, not that much
more rpm deps can solve for this situation.
To me, this seems to be the best and simplest solution. The requirement
for gnome-vfs2-smb is apparently there to make sure the default install
has certain funcionality, so why not delegate that responsibility to the
installation program (i.e. Anaconda)? If the user wants to remove it
later, fine. On upgrades, gnome-vfs2-smb will be upgraded if it's
installed, otherwise it won't be installed.
+1 for letting Anaconda define the default install package set, instead
of using "Requires".
/Peter
11:59 a.m.
On Mon, 2005-01-24 at 10:17 +0100, Peter Backlund wrote:
To me, this seems to be the best and simplest solution. The requirement
for gnome-vfs2-smb is apparently there to make sure the default install
has certain funcionality, so why not delegate that responsibility to the
installation program (i.e. Anaconda)? If the user wants to remove it
later, fine. On upgrades, gnome-vfs2-smb will be upgraded if it's
installed, otherwise it won't be installed.
This course of action has the priorities backward. Priority 1 is that
people
get the functionality they expect. Priority 2 is that tweakers and
tuners
can save a little disk space.
Havoc
10:54 a.m.
On Mon, Jan 24, 2005 at 09:02:15AM +0100, Arjan van de Ven wrote:
> Meanwhile, new packaging for, say, nautilus which has
> Requires(missingok): gnome-vfs2-smb
> and a depsolver that tests RPMSENSE_MISSINGOK drop a sub-tree that
> is optional.
>
> I fail to see a mulberry bush, except in this loopy and endless fretting.
>
> Show me the mulberries *please*.
user goes from package-1.0-1.0 to package-1.1-1.0 which now had a
Requires(missingok): gnome-vfs2-smp. Fine; yum (for the sake of
argument) grabs gnome-vfs2-smp as well and everything is happy.
Now the user gets annoyed by the "bloat" and removes gnome-vfs2-smp.
Still fine.
Then a security update comes out, package-1.1-1.1 and the user of course
upgrades to that. yum will *AGAIN* pull in gnome-vfs2-smp. User gets
really annoyed and considers this not-fine.
As the current answer to "Can I do a yum upgrade of my system?" is
"Read the Release Notes to see what special magic anaconda knows about and
then do the upgrade at your own risk" I think yum/apt/etc shouldn't default
to adding a missingok package when upgrading. This should only be something
that anaconda does. Of course, I don't code for any of the package managers
so it's not up to me.
-Toshio
6:08 p.m.
On Sun, 23 Jan 2005 18:58:02 -0500, Jeremy Katz <katzj(a)redhat.com> wrote:
And, of course, there's the ever fun part about if there's
anything like
this, then _every time you do an upgrade_, you'll get the package added
back.
Thats no different than the current situation with the heavy-handied
use of Requires in the case of nautilus. The package maintainers seem
hell bent of forcing the install of this smb support even during an
upgrade. I'd say any solution that lets an admin uninstall it after an
upgrade.. has got to be better than the current situation where you
have to break a dep chain to get that gnome-vfs2-smb uninstalled. If
all the solutions to choose from are imperfect... the one that
provides the local admin any measure of control seems sane to me. If
we can't prevent this from being installed during an upgrade at least
making it something local admins can remove post upgrade sound good
from a system admin perspective.
-jef"Oh and can I have a pony with every fedora core install? i want a
pony."spaleta
10:42 p.m.
On Sat, 22 Jan 2005 21:39:28 -0500, Jeff Johnson <n3npq(a)nc.rr.com> wrote:
"dependency clutter" presumes that dependencies are
arbitrarily designed to
decrease the quality of your life.
That is not the case.
Instead ...
... nautilus "needs" samba much likes it needs just about every other
bleeping library
in FC4. Why? Because users want "features", and features requires
implementations,
usually in libraries, which use sonames, which are copied into package
dependencies.
Taking a quick peek at the specific nautilus issue raised. The
nautilus's rpms dependancy on the package samba-common is actually the
result of an explicit requires for 'gnome-vfs2-smb.' and not a hard
library dependancy.
gnome-vfs2-smb package requires samba-common through a library dep
libsmbclient.so.0
However, nautilus requires gnome-vfs2-smb though an explicit requires
on gnome-vfs2-smb, a decision made by the packager to ensure that the
runtime detectable smb support is always available when nautilus is
installed to provide a perfectly reasonable and recommended default
behavior for the average gnome desktop user. Some would argue doing
this is bending the purpose of 'requires' field out of necessity to
be used as a 'suggests' or 'recommends' field which rpm doesn't yet
have support for.
I was able to rebuild nautilus with the explicit requires on
gnome-vfs2-smb turned off, which allowed me to remove samba-common
without removing a cascade of gnome components. I did this just as a
double-check to make sure my reading of the deptree was correct.
samba-common now requires the removal of: authconfig-gtk, firstboot,
gnome-vfs2-smb and samba-client.
Clearly this is an example of the tension between providing reasonable
default/recommended featureset and providing a measure of flexibility
for more advanced users and system admins to control which run-time
detectable features are available on their systems. If rpm had a
'suggests' or 'recommends' tag which could be used for such
recommended but runtime detectable options, that would change the
dynamic of this tension greatly. But I am unqualified to comment on
whether or not the flexibility gain worth the effort to implement this
in rpm. I will say that I can imagine situations where corporate
network admins might not want to have the smb support in their linux
desktop installs, so maybe there is a compelling business interest for
red hat to make it easier for those network admins to decide whether
they need that gnome-vfs2-smb feature on the system without
recompiling nautilus for themselves.
-jef
11:13 p.m.
Jeff Spaleta wrote:
gnome-vfs2-smb package requires samba-common through a library dep
libsmbclient.so.0
However, nautilus requires gnome-vfs2-smb though an explicit requires
on gnome-vfs2-smb, a decision made by the packager to ensure that the
runtime detectable smb support is always available when nautilus is
installed to provide a perfectly reasonable and recommended default
behavior for the average gnome desktop user. Some would argue doing
this is bending the purpose of 'requires' field out of necessity to
be used as a 'suggests' or 'recommends' field which rpm doesn't yet
have support for.
The problem here is that the "recommended default" then becomes a forced
necessity. Suddenly, instead of a cool feature, you've got bloat.
"Defaults" should be handled by anaconda, not RPM. In the absence of a
more elegant way of "recommending" a package other than with a
dependancy, the recommendation should simply be left off. If you're
going to require an add-on package, then there's really no point to
putting it in a separate package anyway. The whole situation is
nonsense, really.
But then, this isn't the first time we've had this discussion. However,
certain key individuals are convinced that things are fine the way they
are, and need no fixing.
Yes, dependacy bloat is a problem, but it's not going to be fixed until
the responsible persons are convinced that a problem actually exists.
3:27 p.m.
New subject: suggests/requires in rpm (was: Re: further package removals/potential package removals)
Jeff Spaleta wrote:
However, nautilus requires gnome-vfs2-smb though an explicit requires
on gnome-vfs2-smb, a decision made by the packager to ensure that the
runtime detectable smb support is always available when nautilus is
installed to provide a perfectly reasonable and recommended default
behavior for the average gnome desktop user. Some would argue doing
this is bending the purpose of 'requires' field out of necessity to
be used as a 'suggests' or 'recommends' field which rpm doesn't yet
have support for.
I have run into this kind of problem several times (and I've learned
packaging only two years ago). For example with showimg (an image viewer),
which can use kipi-plugins to add features, or with psi (a jabber client),
which can use qca-tls for SSL support.
The main objection I got from the RH folks when I proposed some kind of
"recommands" before, is that most of the time the dependancies are set at
compile-time, and thus are hardcoded.
But I think that more and more applications use a plugin system to add
features. Those plugins should remain plugins, and thus should not be set
as an hardcoded dependancy.
But of course, adding such a feature in RPM would need a very large amount
of work to be supported properly from rpm to the user's wrappers.
Nevertheless, I think "suggests" support could be added in RPM without
breaking the wrappers, and complete support could be added later on. The
wrapper which do not know of it yet would just ignore it. Would older
implementation of RPM just ignore the tag when asked to rebuild a
"suggests"-enabled spec file ?
It's a lot of work, but I think it is worth it and it can be done one step
at a time without breaking existing software.
Of course, that's just my 0.02 and I don't know the inner workings of RPM
very well.
Aurélien
--
http://gauret.free.fr ~~~~ Jabber : gauret(a)amessage.info
"As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours ; and
this we should do freely and generously." -- Benjamin Franklin
4 p.m.
New subject: suggests/requires in rpm
Aurelien Bompard wrote:
Jeff Spaleta wrote:
>However, nautilus requires gnome-vfs2-smb though an explicit requires
>on gnome-vfs2-smb, a decision made by the packager to ensure that the
>runtime detectable smb support is always available when nautilus is
>installed to provide a perfectly reasonable and recommended default
>behavior for the average gnome desktop user. Some would argue doing
>this is bending the purpose of 'requires' field out of necessity to
>be used as a 'suggests' or 'recommends' field which rpm doesn't
yet
>have support for.
>
>
I have run into this kind of problem several times (and I've learned
packaging only two years ago). For example with showimg (an image viewer),
which can use kipi-plugins to add features, or with psi (a jabber client),
which can use qca-tls for SSL support.
The main objection I got from the RH folks when I proposed some kind of
"recommands" before, is that most of the time the dependancies are set at
compile-time, and thus are hardcoded.
But I think that more and more applications use a plugin system to add
features. Those plugins should remain plugins, and thus should not be set
as an hardcoded dependancy.
The proposal is for "missingok", not Recommends:, Enhances:, Suggests:
or any other
goosey-loosey crapola with poorly defined DWIM that is impossible to
implement, let
alone debug.
The specific difference is that dependencies marked with "missingok" are
passed to
a depsolver, which is entirely at liberty to do whatever it wants with
the information.
And the other difference is that rpmlib is responsibly only for passing
the information
to the depsolver, and then ignoring the dependecy.
That definition is well defined mechanism, unlike Recommends: et al.
But of course, adding such a feature in RPM would need a very large
amount
of work to be supported properly from rpm to the user's wrappers.
Nevertheless, I think "suggests" support could be added in RPM without
breaking the wrappers, and complete support could be added later on. The
wrapper which do not know of it yet would just ignore it. Would older
implementation of RPM just ignore the tag when asked to rebuild a
"suggests"-enabled spec file ?
It's a lot of work, but I think it is worth it and it can be done one step
at a time without breaking existing software.
Of course, that's just my 0.02 and I don't know the inner workings of RPM
very well.
I do know the innards of rpm upside down and inside out, and the
"missingok" implementation is
3 hours work, with no obvious legacy problems.
That is not true for Recommends: et al.
73 de Jeff
5:04 p.m.
New subject: suggests/requires in rpm
Jeff Johnson wrote:
I do know the innards of rpm upside down and inside out, and the
"missingok" implementation is
3 hours work, with no obvious legacy problems.
That is not true for Recommends: et al.
Great ! I don't care how it's going to be called, as long as we can solve
this situation. That's really good news, thanks a lot !
Aurélien
--
http://gauret.free.fr ~~~~ Jabber : gauret(a)amessage.info
If one keeps trying, one successes eventually. Therefore, the more one
fails, the closer one is to success. -- Shadok moto.
7:14 a.m.
New subject: suggests/requires in rpm
On Sun, 2005-01-23 at 17:00 -0500, Jeff Johnson wrote:
The specific difference is that dependencies marked with
"missingok" are
passed to
a depsolver, which is entirely at liberty to do whatever it wants with
the information.
And the other difference is that rpmlib is responsibly only for passing
the information
to the depsolver, and then ignoring the dependecy.
That definition is well defined mechanism, unlike Recommends: et al.
You've made the "definition" easy to implement but left the whole
question of what the user can expect to happen undefined. Choosing not
to define is clever, but it isn't the same as defining something.
"missingok" may be superior to the Debian headers, but calling it well
defined is a poor argument, at least based on what you've said here.
--
Darrin
7:23 a.m.
New subject: suggests/requires in rpm
On Mon, 24 Jan 2005, Darrin Thompson wrote:
On Sun, 2005-01-23 at 17:00 -0500, Jeff Johnson wrote:
> The specific difference is that dependencies marked with "missingok" are
> passed to
> a depsolver, which is entirely at liberty to do whatever it wants with
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> the information.
^^^^^^^^^^^^^^^^^^
You've made the "definition" easy to implement but left
the whole
question of what the user can expect to happen undefined. Choosing not
I, for one, thought Jeff was clear that it's the job of depsolvers
(anaconda, yum, smart, apt) to decide what to do with the extra
information.
-- Rex
8:32 a.m.
New subject: suggests/requires in rpm
I, for one, thought Jeff was clear that it's the job of
depsolvers
(anaconda, yum, smart, apt) to decide what to do with the extra
information.
All that's really been done is to push the decision-making process off
on the depsolvers.
It hasn't resolved the problem, just resolved the problem for rpm.
-sv
8:39 a.m.
New subject: suggests/requires in rpm
On Mon, Jan 24, 2005 at 09:32:17AM -0500, seth vidal wrote:
All that's really been done is to push the decision-making process off
on the depsolvers.
Am I the only one who finds this is the right thing to do? (tm)
Depsolvers solve dependencies. This is just a special kind of dependency
(one amongst many).
Emmanuel
1:01 p.m.
New subject: suggests/requires in rpm
On Mon, 2005-01-24 at 15:39 +0100, Emmanuel Seyman wrote:
On Mon, Jan 24, 2005 at 09:32:17AM -0500, seth vidal wrote:
>
> All that's really been done is to push the decision-making process off
> on the depsolvers.
Am I the only one who finds this is the right thing to do? (tm)
Depsolvers solve dependencies. This is just a special kind of dependency
(one amongst many).
I never said it's not the right thing to do - I was just explaining that
it is not a solution, yet. You just moved where you solve it.
-sv
8:40 a.m.
New subject: suggests/requires in rpm
seth vidal wrote:
>I, for one, thought Jeff was clear that it's the job of
depsolvers
>(anaconda, yum, smart, apt) to decide what to do with the extra
>information.
>
>
All that's really been done is to push the decision-making process off
on the depsolvers.
It hasn't resolved the problem, just resolved the problem for rpm.
Au contraire.
Change no yum code, i.e. don't look at the RPMSENSE_MISSINGOK bit, and
you have exactly
the existing behavior.
Meanwhile, rpm -e becomes possible for end-users, albeit at the expense
of flip-flop through anaconda.
That appears to be progress forward.
OTOH -- without an RFE in bugzilla -- I shall not waste 3 hours on an
implementation, and so no problem
whatsoever has been, or will be, resolved.
Criminey, how hard is it to check a bit that marks an edge in a graph
"optional"? You'ld think this
was NPTL or SELinux.
73 de Jeff
2:29 p.m.
New subject: suggests/requires in rpm
On Jan 24, 2005, Jeff Johnson <n3npq(a)nc.rr.com> wrote:
Meanwhile, rpm -e becomes possible for end-users, albeit at the
expense of flip-flop through anaconda.
That appears to be progress forward.
IMHO what would be make this undoubtedly forward progress would be
some means to adorn the graph arrow with an additional annotation
that would aid the depsolver in figuring out whether to bring in the
additional package, to avoid the very flip-flop that many might regard
as a regression.
The annotation I have in mind would go like `if upgrading from V-R <=
v-r' (where v-r is presumed to be less than the current package V-R),
then bring in the additional dependency.
This addresses the issue of updates/upgrades bringing in new
functionality, but not forcing them onto the user that chose to live
without the new functionality after the upgrade that introduced it.
--
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}
2:54 p.m.
New subject: suggests/requires in rpm
On Mon, January 24, 2005 3:29 pm, Alexandre Oliva said:
The annotation I have in mind would go like `if upgrading from V-R
<=
v-r' (where v-r is presumed to be less than the current package V-R),
then bring in the additional dependency.
This addresses the issue of updates/upgrades bringing in new
functionality, but not forcing them onto the user that chose to live
without the new functionality after the upgrade that introduced it.
I think what you are saying is that you want the missingok dependencies
installed the first time, but not again if the user subsequently removes
them?
If so, is this annotation really required? I think the following rules
accomplish the same thing:
If the currently installed version has the same missingok annotation as is
given in the new rpm, then install each dependency only if an early
version is currently installed (handle each such dependecy like rpm -F).
Otherwise, install each dependant rpm as if it were required, (ie. handle
like rpm -U, it must represent new functionality, or been recently made
optional).
Sean.
10:26 p.m.
New subject: suggests/requires in rpm
On Jan 24, 2005, "Sean" <seanlkml(a)sympatico.ca> wrote:
If so, is this annotation really required? I think the following
rules
accomplish the same thing:
If the currently installed version has the same missingok annotation
as is
given in the new rpm, then install each dependency only if an early
version is currently installed (handle each such dependecy like rpm -F).
Otherwise, install each dependant rpm as if it were required, (ie.
handle
like rpm -U, it must represent new functionality, or been recently made
optional).
Cool, I hadn't considered this possibility. Way to go.
--
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}
9:08 a.m.
New subject: suggests/requires in rpm
On Monday 24 January 2005 22:32, seth vidal wrote:
> I, for one, thought Jeff was clear that it's the job of
depsolvers
> (anaconda, yum, smart, apt) to decide what to do with the extra
> information.
All that's really been done is to push the decision-making process
off on the depsolvers.
Which is what it should do. Depsolvers are becoming the defacto
interface to the packaging system; responsibility may feel burdensome
at times, but it's a pretty clear distinction to implement these
processes at this level.
The less magic RPM does, the better. Depsolvers are more fluid than RPM,
which is why they should acquire the necessary complex logic.
Heretofore mentioned bugzillas already clearly show why magic is a
BadThing at the RPM level and that the depsolvers should be charged to
make these decisions:
--
-jeff
9:25 a.m.
New subject: suggests/requires in rpm
On Mon, 24 Jan 2005 23:08:05 +0800, Jeff Pitman <symbiont(a)berlios.de> wrote:
The less magic RPM does, the better. Depsolvers are more fluid than
RPM,
The less MAGIC we have the better, regardless of where it is. I
honestly don't see how throwing the issues in the bugreports you
listed up a level to the depresolvers is going to help. Frankly, I
think the more and more you ask depresolvers to do in terms of MAGIC,
the more difficult things will become, because invaraibly different
depresolvers will make different choices leading to different behavior
instead of a standardization of behavior. What you suggest is going to
make things much much worse... leading to a situation where packagers
are designing packages with exactly one high-level depsolver in mind..
instead of focusing on what rpm is going to do with the package.
Madness.
which is why they should acquire the necessary complex logic.
Heretofore mentioned bugzillas already clearly show why magic is a
BadThing at the RPM level and that the depsolvers should be charged to
make these decisions:
Right.. so we can all yell at the multiple depsolvers when they all
make uniquely different bad decisions. Magic is a bad thing... but if
magic is going to have to happen.. you only complicate matters by
asking the multiple depresolvers to each figure out how to implement
it for themselves.
-jef
9:59 a.m.
New subject: suggests/requires in rpm
On Monday 24 January 2005 23:25, Jeff Spaleta wrote:
On Mon, 24 Jan 2005 23:08:05 +0800, Jeff Pitman
<symbiont(a)berlios.de>
wrote:
> The less magic RPM does, the better. Depsolvers are more fluid
than
> RPM,
What you suggest
is going to make things much much worse... leading to a situation
where packagers are designing packages with exactly one high-level
depsolver in mind.. instead of focusing on what rpm is going to do
with the package. Madness.
Leading to? Destination already arrived. Name of high-level depsolver:
Anaconda. Name of packagers designing packages with exactly it in
mind: Redhat.
> which is why they should acquire the necessary complex logic.
> Heretofore mentioned bugzillas already clearly show why magic is a
> BadThing at the RPM level and that the depsolvers should be charged
> to make these decisions:
Right.. so we can all yell at the multiple depsolvers when they all
make uniquely different bad decisions. Magic is a bad thing... but
if magic is going to have to happen.. you only complicate matters by
asking the multiple depresolvers to each figure out how to implement
it for themselves.
The yelling already started awhile ago. Finding amicable middle ground
optimal--not a lot of agreement on what that is, yet. I, for one, am
still open to more ideas on it.. What do you think?
--
-jeff
1:05 p.m.
New subject: suggests/requires in rpm
On Mon, 2005-01-24 at 23:08 +0800, Jeff Pitman wrote:
On Monday 24 January 2005 22:32, seth vidal wrote:
> > I, for one, thought Jeff was clear that it's the job of depsolvers
> > (anaconda, yum, smart, apt) to decide what to do with the extra
> > information.
>
> All that's really been done is to push the decision-making process
> off on the depsolvers.
Which is what it should do. Depsolvers are becoming the defacto
interface to the packaging system; responsibility may feel burdensome
at times, but it's a pretty clear distinction to implement these
processes at this level.
The less magic RPM does, the better. Depsolvers are more fluid than RPM,
Not arguing with you - but figuring out the correct, default behavior at
the depsolver level is not easier :)
Anyone who thinks the correct behavior is 'ask the user' is deeply
confused about the understanding the average user has about
package/dependency issues.
We have to have a correct and adequate default state. We can present
options, but we must not rely on the user for this.
-sv
6:05 p.m.
New subject: suggests/requires in rpm
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
seth vidal wrote:
On Mon, 2005-01-24 at 23:08 +0800, Jeff Pitman wrote:
>On Monday 24 January 2005 22:32, seth vidal wrote:
>
>>>I, for one, thought Jeff was clear that it's the job of depsolvers
>>>(anaconda, yum, smart, apt) to decide what to do with the extra
>>>information.
>>
>>All that's really been done is to push the decision-making process
>>off on the depsolvers.
>
>Which is what it should do. Depsolvers are becoming the defacto
>interface to the packaging system; responsibility may feel burdensome
>at times, but it's a pretty clear distinction to implement these
>processes at this level.
>
>The less magic RPM does, the better. Depsolvers are more fluid than RPM,
Not arguing with you - but figuring out the correct, default behavior at
the depsolver level is not easier :)
Anyone who thinks the correct behavior is 'ask the user' is deeply
confused about the understanding the average user has about
package/dependency issues.
We have to have a correct and adequate default state. We can present
options, but we must not rely on the user for this.
For once i agree with every statement in a set of replies :). I do think
that it should be handled by the depsolvers and i to that end i raised a
discussion regarding implementing a feature like this some time ago
(nice and vague:) ). Perhaps we could find some sort of way to integrate
this type of information into the current work we are doing on cleaning
up the yum output?
Describing the extra packages as optional and providing additional
functionality with perhaps a little blurb that describes what it adds
would be a modest first step. Providing the ability to include/deny such
optional packages by default and without approval would be another. I
could see this framed in our current revision of possible yum outputs
for user confirmation of the transaction.
- --
Michael Favia michael.favia(a)insitesinc.com
Insites Incorporated http://michael.insitesinc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFB9Y1WBVsNYjF2rDYRAoVNAJsH/YFXrdF2dY5dtJKk5Aez1+QCXgCghgPD
Lbc7YMpWS5V5XvJ0oBwnQVU=
=tVWk
-----END PGP SIGNATURE-----
2:01 a.m.
New subject: suggests/requires in rpm
For once i agree with every statement in a set of replies :). I do
think
that it should be handled by the depsolvers and i to that end i raised a
discussion regarding implementing a feature like this some time ago
(nice and vague:) ). Perhaps we could find some sort of way to integrate
this type of information into the current work we are doing on cleaning
up the yum output?
Describing the extra packages as optional and providing additional
functionality with perhaps a little blurb that describes what it adds
would be a modest first step. Providing the ability to include/deny such
optional packages by default and without approval would be another. I
could see this framed in our current revision of possible yum outputs
for user confirmation of the transaction.
You've got to keep user output debug level in mind - not in every case
will the user see or want to see that much information - moreover we
need to make sure we don't scare the user too much.
-sv
7:25 a.m.
New subject: suggests/requires in rpm
Darrin Thompson wrote:
On Sun, 2005-01-23 at 17:00 -0500, Jeff Johnson wrote:
>The specific difference is that dependencies marked with "missingok" are
>passed to
>a depsolver, which is entirely at liberty to do whatever it wants with
>the information.
>
>And the other difference is that rpmlib is responsibly only for passing
>the information
>to the depsolver, and then ignoring the dependecy.
>
>That definition is well defined mechanism, unlike Recommends: et al.
>
>
>
You've made the "definition" easy to implement but left the whole
question of what the user can expect to happen undefined. Choosing not
to define is clever, but it isn't the same as defining something.
"missingok" may be superior to the Debian headers, but calling it well
defined is a poor argument, at least based on what you've said here.
OK, so call the scheme "implementable" rather than "well defined".
<shrug>
Unlike Suggests: Enhances: Recommends: which all cater to user expectations,
and have never been well implemented, even in apt.
"Not implemented." has never stopped user expectations before,
"missingok"
will be exactly the same.
73 de Jeff
7:53 a.m.
New subject: suggests/requires in rpm
On Mon, 2005-01-24 at 08:25 -0500, Jeff Johnson wrote:
OK, so call the scheme "implementable" rather than
"well defined". <shrug>
Unlike Suggests: Enhances: Recommends: which all cater to user expectations,
and have never been well implemented, even in apt.
"Not implemented." has never stopped user expectations before,
"missingok"
will be exactly the same.
Fair enough. As long as no depsolver is confused into leaving out a
security update there shouldn't be too much complaining.
--
Darrin
8:16 a.m.
New subject: suggests/requires in rpm
Darrin Thompson wrote:
On Mon, 2005-01-24 at 08:25 -0500, Jeff Johnson wrote:
Fair enough. As long as no depsolver is confused into leaving out a
security update there shouldn't be too much complaining.
A busted mirror or a missing dependency will stop a seurity update far
more effectively
than "missingok", don't fool yerself.
73 de Jeff
9:06 a.m.
New subject: suggests/requires in rpm
On Mon, 2005-01-24 at 09:16 -0500, Jeff Johnson wrote:
A busted mirror or a missing dependency will stop a seurity update
far
more effectively
than "missingok", don't fool yerself.
Certainly. But could missingok ever ever ever stop a security update? Of
course not, so long as packagers or package manager authors don't do
anything stupid. :-D
I think what bothers me about this is that I'm having trouble
identifying what I trust in the before missingok scenario vs. what I
mistrust in the after scenario. I think it's that the correct use of the
feature is distributed so widely that it would be hard for me to
reestablish trust in the new regime.
My guess is that you are right about this. It's just that there's a lot
more to it than meets the eye. I have a little trouble getting my head
around all of it.
I have to be cautious because I have customers who want their precious,
(pant pant) PRECIOUS security updates.
--
Darrin
9:16 a.m.
New subject: suggests/requires in rpm
On Monday 24 January 2005 23:06, Darrin Thompson wrote:
I think what bothers me about this is that I'm having trouble
identifying what I trust in the before missingok scenario vs. what I
mistrust in the after scenario. I think it's that the correct use of
the feature is distributed so widely that it would be hard for me to
reestablish trust in the new regime.
If you trust the provider, then the package should be trusted to do its
job. If not, bugzilla. Barring reference to GPG sigs, using a feature
of RPM is not going to affect trust either positively or negatively:
it's the provider, how they wield the tool, and their historical
performance wielding it.
An update may or may not bring in the missing packages in the
depsolver--this has yet to be implemented, at all. But, this does
nothing but potentially bloat disk space a little. Does that mean you
lose trust? I dunno; but, it's readily resolved. RFE or patch
depsolver is the best bet.
--
-jeff
1:50 p.m.
New subject: suggests/requires in rpm - missingOK
Should the missingOK flag just make you able to *install* a package
without the package which "may be missing", but not upgrade - say if you
have a libary that needs to be upgraded in paralell to an app, and you
upgraded the app but not the lib (because of slow packager etc) - then
some functionality would suddenly just wanish...
1:58 p.m.
New subject: suggests/requires in rpm - missingOK
Kyrre Ness Sjobak wrote:
Should the missingOK flag just make you able to *install* a package
without the package which "may be missing", but not upgrade - say if you
have a libary that needs to be upgraded in paralell to an app, and you
upgraded the app but not the lib (because of slow packager etc) - then
some functionality would suddenly just wanish...
Nah, convoluting install vs upgrade mode behavior changes into
"missingok" would
make everyone's head hurt. Certainly gives me a headache ;-)
Nice and KISSy, "missingok" is a "optional" edge in a dependency graph
until the
depsolver guys catch up ...
73 de Jeff
9:48 p.m.
Jamie Zawinski <jwz(a)jwz.org> writes:
For example: I don't use Windows, ever. This means I don't
use Samba.
But I can't uninstall it, because Nautilus depends on it. Now, I don't
use Nautilus either, but I can't just uninstall *that*, because
control-center depends on it, which I *do* use.
ACK; some packages should be split to avoid such dependencies. 'gnupg'
(which brings 'perl' and 'openldap' into the game (additional 50MB)) and
'kernel' (which wastes 30MB and 6000 inodes of my /) are packages coming
at first into my mind...
If space is tight, the first thing I do is nuke everything except
en_US
under /usr/share/locale/ and /usr/lib/locale/
Just do 'echo "%_install_langs C:en" >>/etc/rpm/macros' and
reinstall
everything (as anaconda neither sets it on fresh installs nor honors it
on upgrades).
Enrico
10:53 p.m.
Enrico Scholz wrote:
Jamie Zawinski <jwz(a)jwz.org> writes:
>For example: I don't use Windows, ever. This means I don't use Samba.
>But I can't uninstall it, because Nautilus depends on it. Now, I don't
>use Nautilus either, but I can't just uninstall *that*, because
>control-center depends on it, which I *do* use.
>
>
ACK; some packages should be split to avoid such dependencies. 'gnupg'
(which brings 'perl' and 'openldap' into the game (additional 50MB)) and
'kernel' (which wastes 30MB and 6000 inodes of my /) are packages coming
at first into my mind...
ACK ACK: packages should be split, dependencies (at least those that are
automagically
generated, the majority these days) are not the problem.
>If space is tight, the first thing I do is nuke everything except en_US
>under /usr/share/locale/ and /usr/lib/locale/
>
>
Just do 'echo "%_install_langs C:en" >>/etc/rpm/macros' and
reinstall
everything (as anaconda neither sets it on fresh installs nor honors it
on upgrades).
Yep.
And no matter what (fairly arcane and obscure) flaws there are
%_netsharedpath /usr/share/doc
is at least as good a solution as
cd /usr/share/doc
rm -rf *
for preventing files from being installed in /usr/share/doc.
Assuming that is what you want to do.
73 de Jeff
Enrico
8:12 p.m.
On 01/22/2005 12:11:32 PM, Jeff Spaleta wrote:
If there is serious interest in slimming Core down.. then a decision
has to be made to define a reference usage case or two so we can get
past personal preference and make decisions based on the design needs
of the usage case goal. If a reference usage case for Core is
suppose
to be a developer oriented workspace thats going to impact the
decisions as to what is important to include. If a reference usage
case for Core is suppose to be a desktop for the average human,
that's
going to impact the decisions in very different ways. If Core is
suppose to provide both.. well guess what.. Core will continue to be
4+ CD images.
I definitely want to see Fedora Core shrink.
I want to see Linux on the Desktop really take off - as in someday see
20% or more marketshare. That only is going to happen with OEM's.
Other than Apple users, most people I know use the version of the OS
that their PC ships with - they don't bother to buy updates let alone
other operating systems. Corporate desktop is different, there they run
whatever IT trusts - which also often is not latest.
Anyway - to get Fedora on OEM's it has to be smaller because up the
cost of support - it's cheaper to train support staff for a smaller
base of software.
IMHO it should be easy for an OEM to start with a smaller base, rip
either KDE or GNOME out (depending upon what their staff is trained
in), rip the dev tools out, add some patented stuff (like GStreamer
plugins from fluendo or whoever) and have well under a gig of packages.
They can do that now, but it is harder because there is a lot more to
sift through.
5:43 a.m.
Le dimanche 23 janvier 2005 à 02:12 +0000, Michael A. Peters a écrit :
IMHO it should be easy for an OEM to start with a smaller base, rip
either KDE or GNOME out (depending upon what their staff is trained
in), rip the dev tools out, add some patented stuff (like GStreamer
plugins from fluendo or whoever) and have well under a gig of packages.
They can do that now, but it is harder because there is a lot more to
sift through.
What I want (and at at a point anaconda was real close to providing
this) is the following process :
1. boot on the first FC or RHEL disk
2. have an alphabetical list of the packages available where I can check
the core packages I need
3. have anaconda compute the deps of my core packages, and propose
either to pull all of them or let me review them one by one (ie display
a list of all the packages it wants to pull in, with the following info
for each of those packages: disk number, all the core dep chains that
pull it in, summary)
4. maybe a screen with package suggestions (new stuff in this release
that's great to have, optional plugins for the stuff I selected)
5. save the resulting ks on floppy or usb flash
6. ability to have the next anaconda release read this ks and restart
the selection process from there
Right now to achieve the same result you have to do a minimal install,
copy the kickstart, manually rpm -e and yum install all the stuff you
want, note all your ops and add th packages -packages to your ks copy,
boot on it to test it, etc
The in-system ks generator is a joke :
1. it's not clear on what steps/parameters are mandatory or not
2. it requires a system install just to generate the ks list
3. it requires the *same* system as the one you want to generate a ks
for. Needless to say on even a small network after a few years you have
to work with multiple RHEL/FC versions so do you really believe the
admins will have a bow with each freaking distro release in just to
manage their ks files (and that includes all the RHEL update releases,
because the package set is not stable even in those!)? They may even not
use a RHEL/FC box themselves !
The general RH bias is/was always to install more stuff when in doubt.
Make all optional plugins mandatory via explicit deps. Dumb down
anaconda so it's more difficult to trim the default rpm groups. Add a
few deps instead of splitting a package when a new release ships a new
utility that requires a behemot like openldap, mysql or perl. The result
is the massive bloat we have today (just when flash-root systems like
mini-itx boxes appear on the market). Plus all the anaconda tricks do
not protect from yum installations, nor manual kickstarts, because
people *want* to trim the installation and will even go to the package
rebuild stage to get it.
Really dependencies should be reviewed more carefully in the rawhide/FC
beta stage and not worked around via massive package over-selection like
it's the case now. Today it's gotten to the point that if one wanted to
really untangle the mess it'd take at least two or three FC iterations
IMHO.
Regards,
--
Nicolas Mailhot
6:34 a.m.
søn, 23.01.2005 kl. 03.12 skrev Michael A. Peters:
On 01/22/2005 12:11:32 PM, Jeff Spaleta wrote:
>
> If there is serious interest in slimming Core down.. then a decision
> has to be made to define a reference usage case or two so we can get
> past personal preference and make decisions based on the design needs
> of the usage case goal. If a reference usage case for Core is
> suppose
> to be a developer oriented workspace thats going to impact the
> decisions as to what is important to include. If a reference usage
> case for Core is suppose to be a desktop for the average human,
> that's
> going to impact the decisions in very different ways. If Core is
> suppose to provide both.. well guess what.. Core will continue to be
> 4+ CD images.
I definitely want to see Fedora Core shrink.
I want to see Linux on the Desktop really take off - as in someday see
20% or more marketshare. That only is going to happen with OEM's.
Other than Apple users, most people I know use the version of the OS
that their PC ships with - they don't bother to buy updates let alone
other operating systems. Corporate desktop is different, there they run
whatever IT trusts - which also often is not latest.
Anyway - to get Fedora on OEM's it has to be smaller because up the
cost of support - it's cheaper to train support staff for a smaller
base of software.
IMHO it should be easy for an OEM to start with a smaller base, rip
either KDE or GNOME out (depending upon what their staff is trained
in), rip the dev tools out, add some patented stuff (like GStreamer
plugins from fluendo or whoever) and have well under a gig of packages.
They can do that now, but it is harder because there is a lot more to
sift through.
Another reason to shrink core, is that a smaller core will make sure
each package will get more developer time => higher quality of the
"main" stuff. And by moving the more obscure packages into extras, that
will make it possible for upstream developers themselves to actually
take controll of their own packages (=> higher quality).
7:53 p.m.
On 22 Jan 2005, at 20:39, Peter Backlund wrote:
This discussion is turning a bit absurd, imo. Just because a package
is
lifted out of Core doesn't mean it will vanish from the face of the
earth. You can still install it from Extras if you need it.
I think what some people is discussing here is not the fact that some
packages will end up in Core or Extras repository: it's the fact that
Anaconda installer should allow to install packages from the Extras
repository easily and automatically, if told so, as it is able to
install packages from the Core repository.
Particularly, I don't mind if KDE, XFCE or whatever ends up in the
Extras repository, but I want to be able to install Fedora Core 4 and
install packages from both Core and Extras in a single pass, during the
installation process. Also, I do want packages in the Extras repository
to be maintained and be bound to the same QA process as Core packages.
3:56 a.m.
On Saturday 22 January 2005 20:53, Felipe Alfaro Solana wrote:
On 22 Jan 2005, at 20:39, Peter Backlund wrote:
> This discussion is turning a bit absurd, imo. Just because a package is
> lifted out of Core doesn't mean it will vanish from the face of the
> earth. You can still install it from Extras if you need it.
I think what some people is discussing here is not the fact that some
packages will end up in Core or Extras repository: it's the fact that
Anaconda installer should allow to install packages from the Extras
repository easily and automatically, if told so, as it is able to
install packages from the Core repository.
Particularly, I don't mind if KDE, XFCE or whatever ends up in the
Extras repository, but I want to be able to install Fedora Core 4 and
install packages from both Core and Extras in a single pass, during the
installation process. Also, I do want packages in the Extras repository
to be maintained and be bound to the same QA process as Core packages.
I disagree here that it should all be under anaconda. If Core is really small
(no nedit, no KDE, no mysql, no postgresql, etc.) but then during firstboot I
can add what I want from Extras.
And yes, there should be iso images of Extras cut when the Core is cut. And
yes, when Core goes "gold", there is a gold version of Extras. Handling of
updates for Extras is another consideration ... like Core (with base and
updates) or just make it the latest (like development).
--
Gene
5:44 p.m.
On Friday 21 January 2005 18:58, Bill Nottingham wrote:
nedit
- legacy interface (motif)
- doesn't support Unicode
I would be disappointed to see nedit removed. If, and only if, Fedora Extras
is real (a lot more real than it has been so far), then moving it to Extras I
can understand. Will I do my own thing and build my own nedit if it is
removed: yes. Will be be a bit pissed: yes. When the latest version is
not built for the current release but is available in rawhide/development, do
I rebuild it for the current release: yes.
Editors are very personal. Once you get use to one, that is your editor and
it is difficult to change no matter if there are better one available. I
have been at this computer stuff for more years than I care to think
about ... nedit is my editor of choice.
--
Gene
7015
days inactive
7029
days old
185 comments
66 participants
participants (66)
-
Alan Cox -
Alexandre Oliva -
Arjan van de Ven -
Aurelien Bompard -
Bill Nottingham -
Carlos Rodrigues -
casimiro barreto -
Chris Adams -
Colin Charles -
Dan Williams -
Darrin Thompson -
Dimitrie O. Paun -
Elliot Lee -
Emmanuel Seyman -
Enrico Scholz -
Felipe Alfaro Solana -
Florian La Roche -
Féliciano Matias -
Gene C. -
Harald Hoyer -
Havoc Pennington -
Herbert Rutledge -
Jamie Zawinski -
Jef Spaleta -
Jeff Johnson -
Jeff Pitman -
Jeremy Katz -
Jim Cornette -
John Ellson -
John Thacker -
Jonathan Andrews -
Kjartan Maraas -
Kyrre Ness Sjobak -
Luciano Miguel Ferreira Rocha -
m g -
Matthew Miller -
Michael A. Peters -
Michael Favia -
Michael Schwendt -
Miloslav Trmač -
Nathan Grennan -
Nick Bargnesi -
Nicolas Mailhot -
Norman Gaywood -
Paul Iadonisi -
Pekka Savola -
Peter Backlund -
Peter Jones -
Peter Robinson -
Rahul Sundaram -
Ralf Corsepius -
Ralf Ertzinger -
Rex Dieter -
Ronny Buchmann -
Rui Miguel Silva Seabra -
Sean -
Sean Middleditch -
seth vidal -
Stuart Children -
Thorsten Leemhuis -
Tomas Mraz -
Toshio Kuratomi -
Troels Arvin -
Trond Eivind Glomsrød -
Tyler Larson -
Ville Skyttä