On Tue, 2007-06-05 at 16:52 -0400, Bernardo Innocenti wrote: > Jeremy Katz wrote: > > It's more like 40. Or 60. Because doing it by region doesn't really > > help much -- languages are spoken across regions and trying to pigeon > > hole them like that just doesn't work. Times however many packages this > > is done for. It gets big _fast_. > > How about just 1? We make package foo and foo-locale with all > locales. > > Space constrained embedded users and lovers of the C locale > would not install them. My mother language is Italian, but I > know few users who actually *like* to use Linux with LANG=it. > The shell is an English/POSIX environment. Any mixture of it > with other languages is actually going to reduce usability for > advanced users. And novices usually don't go in the console. This is an incredibly Western-world-centric view of things that goes over extremely poorly in many other countries. > Anyway, not a big deal for embedded developers: we could > also solve it by setting %_netsharedpath /usr/share/locale > in .rpmmacros. > > > You end up having to track more copies of, eg, changelog data and other > > things that are "common" across a src.rpm set. And yes, that's pretty > > costly. > > I always wondered why we never trim or rotate them at some > point. We're not running a museum. Full history may be > useful for CVS, but for the RPMs we ship, 2-3 years should > be a good compromise. Sure, but 2-3 years can still be a lot of data. > > We used to set it. And then people asked how to add support for a > > language after the install. And the answer was basically "you can't". > > So we don't do that anymore. I'd be open to having a way of setting it > > from, eg, kickstart which is much more likely to be being used in these > > sorts of "small footprint" situations. > > AFAIK, MacOSX's installer does that too. And I don't think > they have a way to add language support later. Actually, > It seems they only made the "install" part easy, as I've > not yet understood how to uninstall packages on OSX ;-) Adding language support later was a very common request. I still see questions about it now that it's relatively easy... at least now, I can give an easy answer ;-) > > deltarpms work by taking the bits you have on disk + the deltarpm and > > combining them to recreate the update rpm. If you've opted not to put > > some of those bits on the disk, then it can't recreate the update RPM. > > If deltas were done on a file by file basis, it would work > even with partial installs. Within the deltarpm, things are done on a file by file basis. But you use the delta + bits on disk to reconstruct the "new" rpm. And then verify it. The idea being that you can then just update the rpm as though you had downloaded the whole thing. Before doing deltarpms, there was a concept called patch rpms which was more "apply the deltas to the files that are there, cross your fingers and hope really hard" ;) That's been abandoned by the SuSE guys in favor of deltarpm because it led to all kinds of problems for them. > How did SuSE address these issues? Anyone knows if they are > still using deltarpms in OpenSuSE? They do. But they also don't support partial installs along these lines. Or at least, if they do, they don't then support using deltarpms later Jeremy -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
