On Mon, 2005-04-25 at 19:52 +0200, Nicolas Mailhot wrote: > Mathias Bauer wrote : > |> This might seems mightily restrictive (and it is) but the end result > is > |> when one file on the system has a problem you know what package owns it > |> and fixing this package is sufficient to heal the system. This is why > |> Fedora Core for example can afford its fast releases - if it had to do > |> an audit of all the files interactions each time like under Windows > |> seamless upgrades would not be possible. > | > |don't apply to the OOo installer. It *can* be used in a fully automated > |way and packages don't overwrite any files from anywhere. We still have > |to add digital signing though (and we will as I mentioned in another > |mail some days ago). > > If this means OO.o internals map well to Linux packages needs and you're > ready to work with me on making native packages happen let's do it.
> If this means you can do the same thing via platform-independent OO.o > bundles and argue there is no functional advantage going the native > route then sorry, it got about the same appeal as a if you proposed to > me to use a separate phone per correspondant because it's too bothersome > for you to use the same hardware as the other links. And I'd agree with > you all the different telephones are functionally equivalent except I'd > like to keep some room in my pockets for something else so that's not > really the point. > > The point is to keep a _single_ software/app/lib database per system, > with a _single_ key/certificate repository, a _single_ update model and > a _single_ point of entry for users. > > And you can argue OO.o is special and should be an exception except > every app writers feels his app is special and wants the very same > exception so that's a direct way to system management hell (be it for > single-user systems of big centrally-managed computer pools) This is really at odds to one another. It is absolutely possible to do both and it is widely accepted to package stuff and have stuff installable by the user. Take perl CPAN for an example. I have installable modules by debian for a few common modules otherwise I can run cpan and install it either centrally for all users or locally for my user only for testing new modules. So there is always a compromise and never a black and white situation. It absolutely IS up to the Linux distributions who can package this themselves. As pointed out they may choose to disable the installer. Can we focus our attentions on the model for storing and distributing the actual extensions. (I hate the word macros...) I like the cpan model and think we should base it around that. -- Ken Foskey OpenOffice.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
