Otto Haliburton wrote: This is because you have all the language components install to begin with. The old languages needs to be updated as well because the old ones are dependent on the old version of openoffice (to continue your example). Just don't install all the stuff you don't want in the first place and you should be good. /Thomas

On Tue, 2005-12-20 at 10:06 -0500, Jeff Spaleta wrote: well, i can agree with you if fedora was a production system, as far as I know it is a development system and the object is to select a complete download, and I guess you must pay the penalty for that, the problem also occurs with the kde update too. I think that there should be a solution that allows you to select. The further problem with the response is in using the exclude config switch you might have a slight problem in excluding everything except the english updates etc. A more positive aspect for the solution is that yum detects the fact that multilanguages are available and prompts for inclusion of all or the inclusion of a selected language giving you the best of both worlds. -- Otto Haliburton <ottohaliburton(a)comcast.net&gt;

On 12/20/05, Otto Haliburton <ottohaliburton(a)comcast.net&gt; wrote: Pretty sure noone sane thinks an "everything" install is a good idea. But you are free to continue to attempt them. As much as I hate agreeing with Steenholdt.. and let me assure you i hate having to do it it... i have to agree with him on this, because of the way the language packages for openoffice are packaged you can't avoid updating the langpacks at all. I think you have a poor understanding of how package dependancies work. So let me take a moment to step through what is going on here. In the case of the openoffice language packages the dependancy is versioned so that language packages are tied to a specific version of openoffice. You can not selectively choose which language packages to update without breaking dependancies. Yum is not going to be re-designed to let you break dependancies to avoid updating language packages...forget you ever had the thought. Example.. on fc4 right now: repoquery --requires openoffice.org-langpack-he_IL openoffice.org-core = 1:2.0.1-143.2.1 <------ VERSIONED DEPENDANCY same thing on rawhide too: repoquery --repoid=development --requires openoffice.org-langpack-he_IL openoffice.org-core = 1:2.0.1.1-1.2 Back on that fc4 system, if I have the package openoffice.org-langpack-he_IL installed and I want to update openoffice.org-core to version 2.0.1-143.2.1 the dependancy situation demands that I also update the language package. Yum isn't going to allow you to delibrately break explicit dependancy chains... no way... no how. -jef

On Tue, 2005-12-20 at 10:48 -0500, Jeff Spaleta wrote: For a "production" box (server) that is performing some defined task(s), I agree that "everything" is a bad idea. For a "power user"/developer box, I don't see any problem with an "everything" install. Hard disk space is cheap and you can find some cool apps you may not have found otherwise. Additionally, I can recall some situations where an application dynamically gets extra functionality and features if other *addon* or *plugin* packages get installed. For example, unless you have "kdeaddons" RPM installed the Konqueror browser doesn't have the ability to save a web page offline in a tarball. The menu item doesn't show up at all, what a mystery for someone not familiar with low level KDE interactions. When I discovered this a couple years ago the only way to get the "kdeaddons" RPMs installed during installation was via an "everything" install. Possibly this has changed now. Personally, I prefer an "Mostly english-only everything install" on my personal boxes. I do an "everything" install, and first thing after the install finishes I run: # trim some fat (1.1GB worth) rpm -e `rpm -qa | grep ^openoffice.org-langpack` # 600MB rpm -e `rpm -qa | grep ^kde-i18n` # 400MB rpm -e `rpm -qa | grep -E ^man-pages-[[:alpha:]]` # 100MB This may be helpful to the original poster. Dax Kelson Guru Labs

Otto Haliburton wrote: There are interesting challenges here... I recently got Linux running on a Sun Ultra 10, and I chose Debian because it's one of the few distributions that will easily install on SPARC. I tried a more-or-less everything install first and found out that X would crash the machine. I didn't really need X on that machine, so I wanted to do an install that had basic development tools (gcc, awk, perl, time, ...) but no X. I was impressed with apt-get, but the text UI for configuring packages in Debian is atrocious. It didn't help that I was using a funky Sun keyboard with the control key in the wrong place, but I found keystroke combinations to be completely unintuitive -- I ended off ticking off a large number of development packages, and sure enough, some of them depended on xlibs, so the dependency resolver added some X windows related packages to the list, and I wasn't so sure if it was trying to install X libraries (which would have been fine) or an X server (which would have turned the machine into a boat anchor.) Debian diehards will probably say that it's not so bad if you are experienced in Debian, but that's the whole point -- if deb-pkg-config confuses somebody with a decade+ of experience in Linux and Unix, what is it like for a real novice? I pine for the days of Slackware, where it was easy to select bundles, or drill down into the bundles, pick out individual packages, get good descriptions of the packages, and easily decide what you want. I end up doing an everything install in Fedora and RHEL when I build new machines because I know there are things I like in the everything install that won't come up in other installs. Because I don't have a good synoptic view of the packages, I can't tell you what they are! Like a lot of people, I'd badly like to have an "english-only" install... I ~would~ like Unicode fonts, I need uxterm and I need Mozilla to render CJK text out of the box (big advantage that Fedora/RHEL has over Linux)... Not because I can understand CJK text, but because I sometimes need to tell what language a site is and sometimes need to make sure that my software isn't double-encoding something. I ~don't~ need 1 GB of language packs. I wish I could do an "everything but Open Office" install. I just don't have any use for it -- and I really don't have any use for clicking on something that's got nothing to do with any kind of Office and then having my machine grind for two minutes to pop up an Open Office window full of garbage. It's not just a matter of bitching about Fedora/RHEL: managing the software you've got is a nightmare on any platform today. The other day I installed the "Yahoo Widget Engine" on my Windows machine, and it never worked... But now it takes ten seconds longer for it to boot and it pops up dialog boxes asking me if I want to upgrade it. I'm happy that people are talking about these issues... Applications like Azureus and Mozilla, for better and for worse, are bringing some problems from Windows to the Unix world, and it would be good to see a solution.

Paul A Houle <ph18(a)cornell.edu&gt; wrote: [...] Since you are here, may I point you at Aurora <http://www.auroralinux.org> 2.0beta2 (loosely based on Fedora 3) runs OK here on my Ultra 1. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513

On Tue, 2005-12-20 at 08:52 -0600, Otto Haliburton wrote: The older 1.1.X openoffice rpms came with an "i18n" package which contained all the languages known to OOo. The 2.0.X language support was split into separate language rpms. If you upgraded from i18n to 2.0.0 the i18n package was Obsoleted by the pile of new langpack rpms. Because there was no way to know which languages from the i18n pack were actually wanted, the only solution was to make all the langpacks obsolete it, that may have led you astray here ? If you installed OOo from scratch and selected only the required langpacks, or upgraded from i18n and then rpm --erased the unwanted langpacks then subsequent yum updates should not (and don't for me) download and install the unnecessary langpacks. C.