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) -- Nicolas Mailhot
