On Fri, Oct 8, 2010 at 4:05 AM, Scott Furry <scott.wl.fu...@gmail.com> wrote: > -> Package Maintainers (I like 'specialists' but let's use the term people > recognize) can build and distribute both installs and updates to different > OS users. We are respecting the OS and working on the OS in a way with which > people get taught/learned/accustomed to use the OS. > > Q01) Can we have repositories for LibO packages? (e.g. deb - > apt.documentfoundation.org or rpm.documentfoundation.org) > > The idea about having a repository does not have to be permanent solution, > but would allow downstream maintainers to pull/mirror packages for their OS > community. LibO (and by extension DF) would gain credibility and good will > in the community. We can start to build rapport and lines of communication > with the PTBs in the different OS groups. Just a thought.
As Charles said, the proper term is "distribution". Different distributions use different binary and patch package formats, have different versions of the libraries that openOffice builds on, different supported processor types, different release schedules, and different policies on software updates, and these even vary between releases of the same distribution (which may need to be supported for many years). This greatly complicates matters. There is also the issue with other software that may make use of bits provided by openSUSE, this may break because of updates not approved by the distribution (if there even is such software). There are, however, tools like the openSUSE build service that make it much easier to distribute native packages for many distributions. I am not familiar with the others, but a number of places, like opendesktop.org websites and the Linux Foundation, are now using the build service to simply the delivery of packages for many distributions simultaneously. So it is, at least, a popular solution. However, distributions are still going to want to release their own versions with their own tweaks, their own branding, and matching their own release schedules and policies, so it may or may not be worth it. > Q02) If there are people in the community that are good at this, would it be > a bother for them put up the binary packages to the documentfoundation.org > servers? As I said, the buildservice could do this mostly automatically. Distributions could also send their own versions back upstream to the website, but if we were going this route it would probably be easier and safer for everyone if the website just pointed users back to the distribution's native version (since it would receive updates vetted by the distribution). > Q03) Could extensions be lumped in with this topic? (to ensure future OOo > extensions don't cause LibO grief as the two projects start to diverge) The linux distribution packaging systems are not really an optimal tools for distributing add-ons. For one thing, they are almost all system-wide, while many users might want to install add-ons on just for themselves, and in corporate environments wouldn't be able to install them at all. So distributions can choose to ship extensions through their package system, and some do, but I don't think using this as the sole or even primary means of doing so. As I mentioned before, the opendesktop.org website like kde-look.org, gnome-apps.org, InkscapeStuff.org, and so on seem to be a better way, to me, to distribute extensions, templates, and other add-ons. The websites are specifically designed for this, and they implement a freedesktop.org standard called Get Hot New Stuff, or GHNS, which is specifically designed to allow programs to search for, identify, categorize, retrieve, and update add-ons. They are used extensively by both gnome and kde for distributing everything from wallpapers and color schemes to desktop widgets and file manager extensions, and they appear to have a mechanism to filter out results that are not compatible with the current version of whatever program is trying to install them. Rather than wasting the time and effort to design an entire new system from scratch, I think it would be better to use an existing standard tool like this, especially if the goal is to play well with the rest of the open-source ecosystem. > One last point I should make here - once a user installs a package, normally > that user should continue to update via package management (dpkg, apt, yum, > et al.) However, OOo and post-divergence LibO has a built-in updating > mechanism. Great for Windows users but lousy for others where superuser/root > permissions are required. Someone pointed out in the previous thread that simply disabling and hiding the update mechanism for non-root users would solve this. There is still the issue with extensions installed via the package manager and those installed on a per-user basis. Ideally, the software would check whether the current user has write permissions for the extension. If not, it would be grayed out or have some other color, would disable the buttons to manipulate it, and would be have a label telling the user he or she does not have permission to make any changes. Users would still need to be able to disable the extension, but they could not uninstall or update it. Another issue is what happens if the extension is installed by the distribution AND by the user. I would think the user version would always have precedence, and the distribution version would be hidden entirely as long as the user version is installed. Perhaps, the user could update the distribution-provided extensions, but rather than changing the distribution version it would download a user-specific version, and this would take precedence. The user should probably be warned that this is going to happen. > -- OS specifics of update and networking could be pulled out of the main > LibO development. > -- It would remove the problems of corrupting an install if not a superuser > (packaged LibO wouldn't have separate updater program for Unix|Linux or if > it was disabled by an ADMIN) > -- a separate update program could then 'check-in' with the servers (once a > week, once a month) to verify if updates are available (get permission from > the user to shut down the current LibO instance, update, then start LibO > back up) > -- and the really cool idea...plays into Charles' idea of enterprise > installation. > A separate install program that is: > - scriptable ( can install/update many computers via a script) > - allows local or remote repositories to be identified > ( a corporate IT Admin downloads behind his/her firewall and users update > from that local store rather than reaching out to the internet) For windows, definitely. For Linux, I don't see any advantage over using the distribution's own package managers. They have all of these advantages, have the advantage of already been in use a long time and have been thoroughly tested, and have the advantage of not interfering with the distribution's packaging policies. It would be rare, in my opinion, for Linux users to even want to use such an updater. -Todd -- To unsubscribe, e-mail to discuss+unsubscr...@documentfoundation.org All messages you send to this list will be publicly archived and cannot be deleted. List archives are available at http://www.documentfoundation.org/lists/discuss/