Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On 2010-10-17 10:05 PM, Paul A Norman wrote: Re early discussion on Wondpws install and unpacked install files... Would they need to be present for the Windows Control Panel/ Add remove Programs/ Support Info - - Repair button to work? Yes. This is why I always store these on a shared network location that everyone always has access to. -- Best regards, Charles -- E-mail to discuss+h...@documentfoundation.org for instructions on how to unsubscribe List archives are available at http://www.documentfoundation.org/lists/discuss/ All messages you send to this list will be publicly archived and cannot be deleted
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
Re early discussion on Wondpws install and unpacked install files... Would they need to be present for the Windows Control Panel/ Add remove Programs/ Support Info - - Repair button to work? Paul -- E-mail to discuss+h...@documentfoundation.org for instructions on how to unsubscribe List archives are available at http://www.documentfoundation.org/lists/discuss/ All messages you send to this list will be publicly archived and cannot be deleted
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On 10/08/2010 10:50 PM, Marc Paré wrote: You are probably right there too. It wouldn't hurt though to try it and see what kind of response the LibO community got from such a service. Maybe from a dependencies point of view it would be too hard to manage still. IMHO, it would be nice if the LibO packages came out prepped for immediate installation/update for distros. I think there would be a huge response from the community to having LibO packages prepped for their distro and available at libreoffice.org. The problem with letting the distro packagers do it is that they do a big push up to prepare for their distro release, but they don't typically push out an OOo update when it becomes available -- they often wait for the next release of their distro. By prepping packages ourselves, I think we'll find that we get a lot more immediate downloads from the user community, and quicker feedback on bugs. Jon -- To unsubscribe, e-mail to discuss+h...@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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
Hi Todd, Am Tue, 12 Oct 2010 16:27:47 -0400 schrieb todd rme: On Tue, Oct 12, 2010 at 2:47 PM, Eric Hoch eric_openoff...@gmx.de wrote: Hi Todd, Am Tue, 12 Oct 2010 13:14:49 -0400 schrieb todd rme: On Tue, Oct 12, 2010 at 8:47 AM, Charles Marcus cmar...@media-brokers.com wrote: On 2010-10-10 12:48 AM, todd rme wrote: There is another, somewhat independent issue that has occurred to me. What about how the components are split up? The issues are somewhat different for windows and mac than they are for linux. At least on my system writer is 19 mb, impress is 11 mb, and calc is 24 mb, while the core is about 120 mb. So the individual applications are anywhere from about 10% to about 2% the size of the core. Together the individual applications are about 85 mb. So yes, they are less than the core components, but I wouldn't say they are insignificant. You could cut out about 40% of the download size if you just wanted some of the smaller components. At the start of the process you would likely have to add those core 120MB to the 19 for writer, the 11 for Impress and the 24 for Calc, meaning that you have 414 MB installed instead of just 174MB for the whole Suite. I know that today hard disks are cheap and have at least 300GB or on desktops 500 or much more likely 1TB but again there are still company and home PCs out there which aren't up to date and on which 414MB compared to 174MB are significant. This calculation is based on your informations I don't have Windows here and so I cannot verify if current LibO only is 174MB under Windows. Eric -- ## de.OpenOffice.org - Office für MacOS X, Linux, Solaris Windows ## Openoffice.org - ich steck mit drin! -- To unsubscribe, e-mail to discuss+h...@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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On 2010-10-12 4:27 PM, todd rme wrote: So yes, they are less than the core components, but I wouldn't say they are insignificant. You could cut out about 40% of the download size if you just wanted some of the smaller components. But they are designed to work together, and as has been explained, splitting them up is far from a trivial task, and would almost certainly introduce all kinds of stability and performance issues. Regardless, I don't see much benefit in continuing to talk about it now... the next step is make a formal enhancement request and see what the developers say as to complexity and/or likelihood of it ever happening. -- Best regards, Charles -- To unsubscribe, e-mail to discuss+h...@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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
Hi Todd, Scott, Am Sun, 10 Oct 2010 00:48:23 -0400 schrieb todd rme: On Sat, Oct 9, 2010 at 9:35 PM, Marc Paré m...@marcpare.com wrote: Le 2010-10-09 16:50, Scott Furry a écrit : On 09/10/10 02:11 PM, Marc Paré wrote: snip I agree, direction from the whole community on this, now that we have hashed it out a bit, would give clearer direction of expectations. snip This could then be put to the community as a new thread and the results could be monitored/taken into note for the future planning of the LibO method of updates from the dev team. Marc Mark, I like you rewrite. I can work with that, mind if I 'borrow it?' ;-) I'll post a new thread shortly. Regards, Scott Furry No problem. That is what we are here for. :-) Marc There is another, somewhat independent issue that has occurred to me. What about how the components are split up? The issues are somewhat different for windows and mac than they are for linux. For windows and mac, if someone, for instance, only wants a database program, should they have to download the entire program suite just to install that one program? There are a couple possible solutions to this (in addition to the status quo). One is that we supply the current all-inclusive installer, as well as a separate installers for the individual parts. I don't know how modular OOo or LibO are at this point but for a quite some time it was and still is known to me that the core of LibO/OOo is the biggest part of the Office and the stand alone app would require to download this core and its own modules meaning that if you install say Draw, Writer and Impress you would have to install the core three times plus three times additional module specific additions and therefore you need more disk space in the end then you will save by not installing a monolith OOo. So I see two tasks here. Task 1: Make OOo less monolith so that you can have small stand alone applications Task 2: Find a proper way to distribute and install them. An alternative is that we provide an online installer, where you download a small program, tell it what you want to install, and it retrieves those bits and installs them. This also has the advantage that the actual download the user has to worry about deleting later is very small, the rest of the downloads would be stored in a temporary directory that would be automatically deleted later. Very bad idea. I know a lot of end-users that are quite frustrated by the fact that they don't own the application they bought on a physical medium and have to re download it time and time again and that sometimes the company even tells them that they reached their maximum download and/or activations and that they now have to call this number or even send their bill to certify they bought the software. I know that we don't have those behavior but we would make the user believe that we are no better than the big money companies. In addition I know that most of us are used to fast internet connections with a lots of bandwidth but this isn't the case when you go out into the wild even here in germany are lots of places were DSL 1000 is the fastest you can get and try to install an whole office only via the net if you are on such a machine. You want the whole package which you download at your company, ask a friend to download and burn on a CD or give it to you on an usb stick. Also think of the older computers out there very slow to install applications and even though they are capable of going online installing e.g. the new Acrobat reader on such an older computer takes its while. I just had to deal with this and now it wasn't an option to use a free PDF reader because the form that needed to fill out was only shown and capable of being filled out correct in Adobe Reader. Eric -- ## de.OpenOffice.org - Office für MacOS X, Linux, Solaris Windows ## Openoffice.org - ich steck mit drin! -- To unsubscribe, e-mail to discuss+h...@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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
Le 2010-10-12 02:32, Eric Hoch a écrit : Hi Todd, Scott, Am Sun, 10 Oct 2010 00:48:23 -0400 schrieb todd rme: There is another, somewhat independent issue that has occurred to me. What about how the components are split up? The issues are somewhat different for windows and mac than they are for linux. For windows and mac, if someone, for instance, only wants a database program, should they have to download the entire program suite just to install that one program? There are a couple possible solutions to this (in addition to the status quo). One is that we supply the current all-inclusive installer, as well as a separate installers for the individual parts. I don't know how modular OOo or LibO are at this point but for a quite some time it was and still is known to me that the core of LibO/OOo is the biggest part of the Office and the stand alone app would require to download this core and its own modules meaning that if you install say Draw, Writer and Impress you would have to install the core three times plus three times additional module specific additions and therefore you need more disk space in the end then you will save by not installing a monolith OOo. So I see two tasks here. Task 1: Make OOo less monolith so that you can have small stand alone applications Task 2: Find a proper way to distribute and install them. An alternative is that we provide an online installer, where you download a small program, tell it what you want to install, and it retrieves those bits and installs them. This also has the advantage that the actual download the user has to worry about deleting later is very small, the rest of the downloads would be stored in a temporary directory that would be automatically deleted later. Very bad idea. I know a lot of end-users that are quite frustrated by the fact that they don't own the application they bought on a physical medium and have to re download it time and time again and that sometimes the company even tells them that they reached their maximum download and/or activations and that they now have to call this number or even send their bill to certify they bought the software. I know that we don't have those behavior but we would make the user believe that we are no better than the big money companies. In addition I know that most of us are used to fast internet connections with a lots of bandwidth but this isn't the case when you go out into the wild even here in germany are lots of places were DSL 1000 is the fastest you can get and try to install an whole office only via the net if you are on such a machine. You want the whole package which you download at your company, ask a friend to download and burn on a CD or give it to you on an usb stick. Also think of the older computers out there very slow to install applications and even though they are capable of going online installing e.g. the new Acrobat reader on such an older computer takes its while. I just had to deal with this and now it wasn't an option to use a free PDF reader because the form that needed to fill out was only shown and capable of being filled out correct in Adobe Reader. Eric Hi Eric: You have some very valid points. Could you fill out the survey that is being done on the list? Look for the thread called [tdf-discuss] Survey|Opinion - LibreOffice Install and Update. The data is being collected as a lot of user opinions are appearing on too many threads. The survey thread is trying to collect all of these issues on one thread. Your remarks would be interesting to have on the survey thread. Marc -- To unsubscribe, e-mail to discuss+h...@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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On 2010-10-10 12:48 AM, todd rme wrote: There is another, somewhat independent issue that has occurred to me. What about how the components are split up? The issues are somewhat different for windows and mac than they are for linux. The bottom line reality is, they are not split up now, and doing so would most likely be a massive undertaking. So, maybe this could be discussed as a long range possibility for version 5, 6 or 7, but it isn't something that has any possibility of happening anytime in the near or not so near future. -- Best regards, Charles -- To unsubscribe, e-mail to discuss+h...@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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On 2010-10-12 1:14 PM, todd rme wrote: In a sense, they are split up. In Linux most distributions seem to split them up, at least all the ones I have used do, and in windows it is possible to only install the components you want. I have never tried it on Mac so I don't know for certain. The point is, a split up install doesn't really accomplish much of anything - because each app shares the vast majority of the working cde base, installing just one app only saves a few MBs of space, so there isn't any real point to it other than it feels good to some people. That said, it doesn't bother me as long as it doesn't consume a lot of resources to [continue to] provide the ability to do it. -- Best regards, Charles -- To unsubscribe, e-mail to discuss+h...@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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On Tue, Oct 12, 2010 at 2:47 PM, Eric Hoch eric_openoff...@gmx.de wrote: Hi Todd, Am Tue, 12 Oct 2010 13:14:49 -0400 schrieb todd rme: On Tue, Oct 12, 2010 at 8:47 AM, Charles Marcus cmar...@media-brokers.com wrote: On 2010-10-10 12:48 AM, todd rme wrote: There is another, somewhat independent issue that has occurred to me. What about how the components are split up? The issues are somewhat different for windows and mac than they are for linux. The bottom line reality is, they are not split up now, and doing so would most likely be a massive undertaking. In a sense, they are split up. In Linux most distributions seem to split them up, at least all the ones I have used do, and in windows it is possible to only install the components you want. More or less right. More below. I have never tried it on Mac so I don't know for certain. On the Mac this isn't possible at the moment. So on Linux, they will be split up whether we want them to be or not. The question is whether they will be split up in a consistent manner across distributions or an inconsistent manner. I would say a consistent manner is better. Yes they are split up, but if you take a closer look nearly all the packages depend on one big core packages and smaller application packages and you always need this big core package, even if you only wanted to install the Math-Editor or Impress. Afaik this is for historical reasons when LibO still was StarOffice and featured it's own desktop, email and organizer. For windows, since the installer already knows how to only install the parts you want, and the updater must be able to only download the updates for the parts you actually have installed, then if we combine the updater and installer into one program it shouldn't be too difficult during installation to make it only download the parts you actually want to install. For Windows it's the same, one big core and therefore you only save a few MB if you decide to install only Writer and Calc and not Impress and Draw. You would have to break up this big LibO core if you really like to have stand-alone applications that would save disk space if you don't want to install the applications you don't want to. You would have to go through the code see which parts of this big block are needed by every application and which are application specific and then rewrite the new stand alone applications. I don't know if the above is right from a coders point of view but from an end-user point of view I understood it this way. Eric At least on my system writer is 19 mb, impress is 11 mb, and calc is 24 mb, while the core is about 120 mb. So the individual applications are anywhere from about 10% to about 2% the size of the core. Together the individual applications are about 85 mb. So yes, they are less than the core components, but I wouldn't say they are insignificant. You could cut out about 40% of the download size if you just wanted some of the smaller components. -Todd -- To unsubscribe, e-mail to discuss+h...@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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
In data venerdì 08 ottobre 2010 23:15:18, todd rme ha scritto: Is the opendesktop.org type proposal for the entire program, or just for the extensions, dictionaries, galleries, extensions, language packs, grammar checkers, and other addons? I am suggestion it be used for add-ons only. So extensions, dictionaries, templates, clipart, icon themes, and so on. Things that are small, have no dependencies outside of the libreoffice itself, would likely be installed on a per-user basis, and where third-party and user-made content would be common. +1 -- Valter Registered Linux User #466410 http://counter.li.org Kubuntu Linux: www.kubuntu.org OpenOffice.org: www.openoffice.org -- To unsubscribe, e-mail to discuss+h...@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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On 09/10/10 10:48 PM, todd rme wrote: There is another, somewhat independent issue that has occurred to me. What about how the components are split up? The issues are somewhat different for windows and mac than they are for linux. For windows and mac, if someone, for instance, only wants a database program, should they have to download the entire program suite just to install that one program? There are a couple possible solutions to this (in addition to the status quo). One is that we supply the current all-inclusive installer, as well as a separate installers for the individual parts. An alternative is that we provide an online installer, where you download a small program, tell it what you want to install, and it retrieves those bits and installs them. This also has the advantage that the actual download the user has to worry about deleting later is very small, the rest of the downloads would be stored in a temporary directory that would be automatically deleted later. It occurred to me that this is, in essence, what the updater would do. So really you would only need one program, the updater, which would also be able to handle the original installation. You could just download the updater and have it retrieve the latest versions of whatever parts of the program you want from the servers. This also makes it easier for users who, say, install writer and find they like it to easily install other components right from within the program. For Linux, the issue is how the parts of the suite are divided up and named. Different distributions use lots of different ways to break up the suite into individual packages and lots of different names for those packages. It is not possible to force distributions to use any particular naming scheme, but I think that providing recommendations and guidelines for how the packages should be divided up would be very helpful. Users would have a better idea what they need to install to get the features they want, tech support will be easier because people using different distributions can communicate more effectively about what they have installed, and switching between different versions of the software provided by different groups would be easier. Of course the content of these guidelines would require a lot of discussion with distributions, but I would like to think distributions would be willing to follow such guidelines if they are reasonable. -Todd Todd, Nice thought. As soon as I read your post I was smacking my forehead as this makes quite a bit of sense to me. As I understand the current install from a strictly Debian/Apt perspective, what you describe exists in some form. LibO has a common or core package, individual packages for the different major LibO components and (I'm assuming here) the LibO Basis. If you have a look at Nicola's deb work ( http://download.tuxfamily.org/gericom/libreoffice/ ) you can get a better idea of how LibO's components are packaged for Debian/Ubuntu/Mint etc users. The devs would have to comment further about technical feasibility, but from this user's point of view I like the idea. Regards, Scott Furry -- To unsubscribe, e-mail to discuss+h...@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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On Sat, Oct 9, 2010 at 1:50 AM, Marc Paré m...@marcpare.com wrote: KDE does not offer binaries as a rule. There are Mandriva binaries on the KDE ftp server, but that is the only distribution that has binaries on the KDE server. Further, I do not think that those are actually produced by KDE itself, KDE was simply nice enough to host them. In fact several people, myself included, have suggested to KDE developers that they release official binaries and they refused, saying that it was the responsibility of the distributions to produce the binaries. -Todd You are probably right there too. It wouldn't hurt though to try it and s ee what kind of response the LibO community got from such a service. Maybe f rom a dependencies point of view it would be too hard to manage still. IMHO, it would be nice if the LibO packages came out prepped for immediate installation/update for distros. It sounds like you thought that it was a good idea for KDE updates too. Marc I am not saying it is a bad idea, although it may be more work than it is worth. What I am saying is that we shouldn't just go and do it on our own, we need to talk to individual distributions to find out how to make this as useful as possible for them and how to eliminate or at least minimize any conflicts it may cause. I don't think decision should be made unilaterally by us, I think it needs to be made with a lot of discussion with the distributions. It isn't a bad thing necessarily, but it has the potential to cause conflicts, which is the last thing a budding fork wants to do. -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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On 10/09/2010 06:23 PM, Scott Furry wrote: And as suggested by the Go-OO site, the rationale for distribution was to avoid some of the politics and interpretations of open source that can occur. Packaging to me just makes sense. +1 The current version of Thunderbird that is available in the Ubuntu repostory is 2.0.0.24. Thunderbird 3.1.1 is in the PPA. The current version available from MozillaMessaging is 3.1.4 If packaging is left exclusively to the distros, what are users of those distros to do, when the current version is not packaged by the distro? Do you really want to people; Sorry, we can't help you, because the version you are using is no longer supported?, even if they are using the most current version available from the distro repository? I'm using Thunderbird as an example of what happens when distros don't keep up with current versions. There are packages that have dropped out of both the official repository, and the PPA. OOo in the official Ubuntu repository is version 3.1. In the PPA 3.2 is available. jonathon -- No human will see non-list, non-bulk, non-junk email sent to this address . It all gets forwarded to /dev/null -- To unsubscribe, e-mail to discuss+h...@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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On 09/10/10 02:11 PM, Marc Paré wrote: snip I agree, direction from the whole community on this, now that we have hashed it out a bit, would give clearer direction of expectations. snip This could then be put to the community as a new thread and the results could be monitored/taken into note for the future planning of the LibO method of updates from the dev team. Marc Mark, I like you rewrite. I can work with that, mind if I 'borrow it?' ;-) I'll post a new thread shortly. Regards, Scott Furry -- To unsubscribe, e-mail to discuss+h...@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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
2010/10/9 Scott Furry scott.wl.fu...@gmail.com: And IMO that is the point. Distributions will only incorporate into the releases what /they feel/ is appropriate. And is that wrong? If you want the last on your computer as soon as possible, then you need to change to a rolling release distro... There is a reason because there are so many distros out there: they are different. If you need to upgrade the very second there is a new version of software X then you need a bleeding edge distro, but don't protest when your system dies after an ordinary update. If you want to be safe then use a conservative distro that do not change package versions on its life cycle, but don't protest if it is outdated. It is your choice. That's why I like openSUSE so much: in its core, it is a solid distro but if you feel adventurous you only need to enable the proper repo and you'll be updated on _that_ component, without risking the whole system. -- To unsubscribe, e-mail to discuss+h...@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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
Le 2010-10-09 16:50, Scott Furry a écrit : On 09/10/10 02:11 PM, Marc Paré wrote: snip I agree, direction from the whole community on this, now that we have hashed it out a bit, would give clearer direction of expectations. snip This could then be put to the community as a new thread and the results could be monitored/taken into note for the future planning of the LibO method of updates from the dev team. Marc Mark, I like you rewrite. I can work with that, mind if I 'borrow it?' ;-) I'll post a new thread shortly. Regards, Scott Furry No problem. That is what we are here for. :-) Marc -- To unsubscribe, e-mail to discuss+h...@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/
Re: [tdf-discuss] Automatic Updates
Hi Scott, Am Thu, 07 Oct 2010 17:49:48 -0600 schrieb Scott Furry: On 07/10/10 05:00 PM, Charles Marcus wrote: On 2010-10-07 6:05 PM, Scott Furry wrote: On 07/10/10 03:04 PM, Charles Marcus wrote: Maybe what is needed is some simple communication to the major distros to see what form would be best. I cannot imagine this would be that difficult - they should all be able to work with standard tarballs and do whatever is needed on their end to make it work. Not all of them. Case in point is the person who put together the Debian packages (Nikola Yanev - great work BTW :D ). There are others out there in the community. It would be great if they (and their skills) could be be brought together allowing for a one-stop-download location of packages for the different OS distributions. This would then be considered the upstream repository from which the various OS distribution teams could then mirror/pull down LibO for distribution to users of that OS. +1 This is a really good idea and some from german community were and are still working on getting the major distro package maintainers of OOo to one table and according to Mechtilde she had quite some success during FrosCon or was it OOoCon? I do not think that LibO should be in the business of providing individual distro packages - let the distro package managers do that. It will free up lots of developer resources to focus on programming, not building/providing packages. Agreed. Most, if not all, of the major distributions build the packages from source. Mostly because they add additional patches to either remove functions that don't match their policies and/or are possibly patent protected, are not 100% legal, not 100% free in the way the distribution understands it, etc. The Debian distribution has over 25,000 different packages in their repository. You think Debian has the time to look after this stuff? Yes, they do so. Rene builds every single OOo Milestone for Debian so that he can apply or remove patches and make OOo meet the debian guidelines. Especially since its staffed with volunteers around the globe? If somebody from the organization and/or community does not do the work (or DF pays someone to do it) LibO will either *never make into the repositories* -or- *become an extremely low priority* for distribution. Were did you get this information from? Which distribution maintainer told you this? Okay... but for a package as large as LibreOffice, it seems to me that a .diff approach would be much better... the only time it wouldn't be practical is for major updates (ie, going from 2.0.1 to 3.3)... but code the update routine to check for that and just download the new version, uninstall the old version and install the new version. Again...a package is supplied in a compressed archive format, albeit with a different extension. sigh so compress it. That's what the workflow of creating a deb/rpm/et al does. Debian packages are standard Unix ar archives that include two gzipped, bzipped or lzmaed tar archives: one that holds the control information and another that contains the data. Yes, and the deb package maintainers generally pull *the source* from the source provider (in this case, the LibO repositories), then builds their packages. Right. Again - let the distro package maintainers do the heavy lifting there... all LibO needs to do is provide access to the source. See my comments above. This is why I suggestion packaging specialists. See my comments about Debian above. I read them but they aren't quite right. I maybe wrong too and in the end only rene could really tell how he works on the Debian LibO/OOo. Eric -- ## de.OpenOffice.org - Office für MacOS X, Linux, Solaris Windows ## Openoffice.org - ich steck mit drin! -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
Per Eriksson wrote: Do we have skilled people here who are interested in beginning with this effort, and maybe start planning for this feature? I've always been interested in pushing things like this forward ;-) Hi Per, let me Cc two MSI packaging experts to comment on patchability experiences. Regarding Linux - I skipped most of the discussion, but really - you do *not* want to bypass the distro update mechanism. You really don't. It's duplicating effort, will likely not result in any better user experience - and, conversely, will annoy distro people, while we actually want to encourage them to actively participate in LibO development. Cheers, -- Thorsten -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
On Fri, 2010-10-08 at 09:23 +0200, Thorsten Behrens wrote: Per Eriksson wrote: Do we have skilled people here who are interested in beginning with this effort, and maybe start planning for this feature? I've always been interested in pushing things like this forward ;-) Hi Per, let me Cc two MSI packaging experts to comment on patchability experiences. Hello Thorston, I wonder if you could ask them if they any opinion on the CoApp project as a possible solution - perhaps. It's not even close to ready, but just curious what would think about that for the future. http://coapp.org/ Thanks Drew Cheers, -- Thorsten -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
Hi Am Fri, 8 Oct 2010 00:18:19 +0700 schrieb Nguyen Vu Hung: On Thu, Oct 7, 2010 at 4:27 AM, Michele Zarri m.za...@gmail.com wrote: On 06/10/10 22:21, Jean Hollis Weber wrote: On Wed, 2010-10-06 at 14:21 -0400, Charles Marcus wrote: On 2010-10-06 2:06 PM, Charles Marcus wrote: Yes there is... use the MSI system, which will take care of things li k e unpacking to the environments /tmp directory, launching the installer after unpacking (like it does now), then - and here is the trickey pa r t I guess - detect a current installation, and offer to upgrade it, or t o install a parallel version. Oh - and one thing that I'd really like to see is a simple 'incrementa l updater' that just downloads a 'patch' file and patches itself, like Firefox and Thunderbird and lots of other programs do now. +10 --Jean +1 +1. And for Mac OS X, as it doesn't (?) have a package management system, we can leave the update agent as it is. There are various systems that take care of applying updates on Mac OS X but I don't know the name of the most popular one and if it has a license that allows it to use with LibO. However I know that when you use the underlying BSD to create pkg-packages for installation you can make update packages. While this would solve the automatic update problem partially it again would bring up discussions which is the right way to install Mac OS X applications. For the hardcore Mac user there is no other way than dragging and dropping the app into a folder he likes it to be and run it. However the switcher, most of the time coming from windows, is used to make a double click and either an installation routine occurs. If no installation routine occurs I've seen switcher use the app out of the diskimage all the time. They simple didn't copy the app into their application directory they left the dmg on their desktop/another folder, opened it every time they wanted to use the app and ejected it afterwards. I myself would prefer the drag and drop way and see if any of the licenses the automatic update mechanism used into apps like Bean, iTerm, MacTracker, VLC, Thunderbird is compatible with LGPL v3 and therefore the mechanism could be used in LibO. Eric -- ## de.OpenOffice.org - Office für MacOS X, Linux, Solaris Windows ## Openoffice.org - ich steck mit drin! -- To unsubscribe, send an empty 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/
LibO Install/Update ( was [tdf-discuss] Automatic Updates)
Hello all, I'm thinking the its time to dig out of the weeds/details and make this a more meaningful discussion for everyone. I'll do my best to avoid excessive verbiage, as well as keep the my soap box stances to a minimum. Charles M (the Original Poster - OP) thought that a better install update mechanism was needed. The discussion likened this to what Mozilla is doing for Firefox, et al. Now, examples and comparisons aside, many expressed thoughts that this was a much needed feature. However, there were some differences realized in how this could be achieved for the different OS platforms (e.g. Unix|Linux|Windows). Unfortunately, AFAICR only one Mac user identified them self and commented on this topic. So apologies to the Mac User crowd (I now you're out there somewhere) ;-) So,lets start with the Unix|Linux crowd: - 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. 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? 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) 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. Q04) How hard would it be to pull out the Update Mechanism and make it a stand-alone program? (before everyone jumps to 'reply' - let me talk about Windows - this question will then become self-evident) For the Windows crowd: The current install is, to put it mildly, less than desirable. Negative comments were made about how the current installer on Windows behaves. These, IMHO, were fair and critical observations. Q05) Can the current install be cleaned up? Users cited having left over files on the desktop and not being aware that one has to uninstall the old version to install the later version (big PITA in my books). Q06) Do we have people that can work on the Windows Installer? Now...as for my left over question above...I believe that a separate 'Update Mechanism' independent of LibO would be a boon for a variety of reasons. -- 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) Q07) Does this seem a useful way to push into enterprise/group usage of LibO? Q(rhetorical)) Am I dreaming in Technicolor/Panavision or just 720p HD? I would very much like to hear from the community on this one (and you Mac users - don't be shy). Regards, Scott Furry -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
On 8.10.2010 9:23, Thorsten Behrens wrote: Per Eriksson wrote: Do we have skilled people here who are interested in beginning with this effort, and maybe start planning for this feature? I've always been interested in pushing things like this forward ;-) Hi Per, let me Cc two MSI packaging experts to comment on patchability experiences. Regarding Linux - I skipped most of the discussion, but really - you do *not* want to bypass the distro update mechanism. You really don't. It's duplicating effort, will likely not result in any better user experience - and, conversely, will annoy distro people, while we actually want to encourage them to actively participate in LibO development. Cheers, -- Thorsten +1 I'm compiling Croatian version since OOo 2.0. And lately some of linux power users are asking why Croatian version is not available *via distro update mechanism*. I have to admit that they are right despite a will that OOo/LO is available via automatic updates. Robert -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
On 2010-10-07 7:49 PM, Scott Furry wrote: On 07/10/10 05:00 PM, Charles Marcus wrote: On 2010-10-07 6:05 PM, Scott Furry wrote: On 07/10/10 03:04 PM, Charles Marcus wrote: I have seen an ActiveX plugin installed in Firefox (which I promptly removed). There was only one *3rd party* effort that I recall from a long long time ago that made any real progress, but it didn't work for anything that I ever tried and it was buggy as hell, then development died while Firefox was at version 1.5... But I guarantee you that you never, ever saw an ActiveX Firefox plugin installed via Windows/Microsoft Update, as you said you did. Your previous text led me to believe you were suggesting that the person doing the packaging was to edit the source code. This person doesn't have a need to open up and/or change source code. Sometimes, yes, they absolutely do, for lots of reasons... what if upstream makes a bad decision (like when Oracle decided to remove the colored icons from OOo in version 3.2.1)? What if there's a patch available that alters the app in a favorable way (in the package maintainers opinion)? What if an easily fixable bug or security hole is slow to be fixed by upstream? The package maintainer can take care of it. I was speaking to an updater for Windows... there never has been one. What about Windows Update? ?! Are you being intentionally obtuse? Obviously I meant an incremental updater for the Windows version of OOo. From a non-os software side, I do recall seeing a update/notify program. Can't remember the name and I no longer can find the link. A notifier is not an incremental updater. There are lots of notifiers. I do not think that LibO should be in the business of providing individual distro packages - let the distro package managers do that. It will free up lots of developer resources to focus on programming, not building/providing packages. The Debian distribution has over 25,000 different packages in their repository. According to what I have read, while some debian evangelists like to throw that number around, because of the way debian often breaks a single application up into multiple packages, the total number of *applications* is actually considerably less than that. You think Debian has the time to look after this stuff? Yep, they do it all the time, as do every other package maintainer for every other distro out there. That's precisely what being a package maintainer is all about. If somebody from the organization and/or community does not do the work (or DF pays someone to do it) LibO will either *never make into the repositories* -or- *become an extremely low priority* for distribution. Objection: assumes facts not in evidence (ie, you're wrong). This is why I suggestion packaging specialists. See my comments about Debian above. snip DF already provides access to the source, as well as instructions on how to build the source, both available from the DF home page. sigh I know this Scott - but again you are missing the point. Historically, building OOo has always been very problematic for many reasons, which I guess is why they got into the habit of providing the actual packages (rpms/debs) themselves. That said, I can see the argument for providing spec files (rpm and/or deb), and absolutely Windows needs installers (dunno enough about the Mac packaging system/process to comment on it)... And just to be clear... I'm not saying it is a bad thing or wrong to provide these packages - a lot of projects do it. What I'm saying is that with a project of this size and complexity, the more the devs can offload onto others (like building packages), the more resources are available to develop the application. But as always - I may be totally off-base about this, so this will be my last comment about it. If the LibO devs say this isn't a big deal and providing these packages is not consuming a lot of their resources, then discussing it is just a lot of noise about nothing... :) I suspect that my strict-*nix focus and trying to communicate non-windows may also be an issue. And I admit my coming from a windows background (I do manage a few gentoo servers, but am definitely *not* what I would call 'fluent' in the *nix's) does cause me to make bad assumptions about things *nix at times... Its not about historical (at least I don't think it is) perspective. IMHO, its about how the *nix community at large functions, which can cause someone not versed in it to become exasperated. Interesting comment, seeing as you seem to be unaware of the fact that most *nix distros have their own package maintainers that don't rely on packages being provided to them by upstream, instead building them from scratch from the upstream source repository. ;) Somewhere in my bookmarks is a link to the cathedral and the bazaar, a book that discusses differences between commercial and open-source development. Would that be of interest to you? Thanks, but it's
Re: [tdf-discuss] Automatic Updates
On 2010-10-08 3:23 AM, Thorsten Behrens wrote: Per Eriksson wrote: Do we have skilled people here who are interested in beginning with this effort, and maybe start planning for this feature? I've always been interested in pushing things like this forward ;-) let me Cc two MSI packaging experts to comment on patchability experiences. Thanks... :) Regarding Linux - I skipped most of the discussion, but really - you do *not* want to bypass the distro update mechanism. You really don't. It's duplicating effort, will likely not result in any better user experience - and, conversely, will annoy distro people, while we actually want to encourage them to actively participate in LibO development. While I agree totally as far as packages installed by the distro's package management system, you (and others) seem to be forgetting two things: 1. it would be the package maintainers responsibility to disable the native auto-updater, thus preventing the user from accessing the native auto-updater in the first place, and 2. one use case that may occur more often than you think - those power users that install from source, thus totally bypassing their package management system. Inmho, #2 should be the deciding factor. If a user does this, then the native updater should be enabled by default (but could be disabled by the user with a compile time switch). -- Best regards, Charles -- To unsubscribe, send an empty 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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
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
Re: [tdf-discuss] Automatic Updates
Charles Marcus wrote: 2. one use case that may occur more often than you think - those power users that install from source, thus totally bypassing their package management system. Hi Charles, users installing from source don't need no update management at all - they can just git pull rebuild. Especially on Linux, this gives you bleeding edge LibO everytime you like - e.g.: http://www.freedesktop.org/wiki/Software/LibreOffice/HowToBuild#Ubuntu.28Lu cid.29 (that's one of the true killer features of Linux - you get the whole build system tools with just a simple apt-get build-dep openoffice.org can have a go - on win32, you install msvc stuff all day long) Cheers, -- Thorsten -- 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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
2010/10/8 Marc Paré m...@marcpare.com: So just to simplify it for those who are like me and who do not realize t he process behind the opendesktop.org update system (I'll use KDE4.5.X as an example): *** please correct these if I am wrong *** If you want to update your wallpaper, you can right-click on the desktop area, choose Folder view settings and then Get more wallpapers, this will connect you with the kde-look.org (hosted by opendesktop.org) and it will get for you the latest wallpapers from the site. This is also used i f you want to change you KDE themes or ... on the KDE desktop. All of these updates are taken care of by the opendesktop.org standard. (The same has apparently been adopted by the Gnome people too.) The suggestion here, is that rather than having different Linux distros using their own updating process (rpm, deb, ...), LibO could adopt the opendesktop.org standard. This will reduce the amount of work needed when a new version of LibO is announced. There is a tiny bit of missing info here ;) The kind of stuff you find on kde-look.org weights no more than some hundreds of KiB (maybe, a bit more of a MiB but usually a lot less) while a normal LibO install is near 170 MiB... These sites are for add-ons only (walpapers, plasmoids...): nothing more, nothing less. Non package manager installs must be avoided by normal users (the risk to end with a mess is too high), and power users will not have problems with installing by hand whatever they need. For example, right now I have: OOo 3.2.1 vanilla (for real work) OOo 3.2.1 Novell build (for multimedia ppts that arrives to my inbox) OOo 330m9 (testing) OOo 300m89 (testing) LibO 3.3 beta1 (testing) (yes, I'm a compulsive tester... ;) ) everything running without conflicts on a single account and without problems... but I do not recommend this for normal users. I cannot speak for other OSs, but best way to install things on Linux is through repositories. Second best way to install things on Linux is using by hand your package manager (.tar.gz files with rpms or debs). Everything else is only for crazy people. Remember: users are human beings, not computer geeks ;) -- 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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
As todd rme has suggested, there exists automated packaging tools. I had not run across that in my readings. I don't use openSUSE, but good to know. My original suggestions regarding a separate repository had been meant to avoid 'package purgatory' where the distributions would relegate LibO to, strictly for example, debian/unstable or debian/experimental. This may preclude the average user from finding and installing LibO to their computer. Even if there are build services available, the suggestion of packaging LibO , even if it was temporary, was to enable LibO availability for the average user. I'm under the assumption that distributions won't pick up LibO just because of what it once was. Sure, other distributions will apply their own stuff to the packaging (Ubuntu being the prime example) but can we put LibO *now* into the hands of the average user? The idea of a distinct and stand-alone updater was to allow for the different use cases with variable distribution/OS platforms, end use environment (single user vs group vs enterprise). The idea is not to build something from scratch, but to pull out the existing updater and make a standalone program. As a standalone program, it can be tweaked/altered/improved without affecting the revision of the main program as a whole. Regards, Scott Furry -- 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/
Re: [tdf-discuss] Automatic Updates
On 2010-10-08 11:35 AM, Thorsten Behrens wrote: users installing from source don't need no update management at all - they can just git pull rebuild. Especially on Linux, this gives you bleeding edge LibO everytime you like - e.g.: Well... different users have different skill levels, but yeah, I mostly agree... (that's one of the true killer features of Linux - you get the whole build system tools with just a simple apt-get build-dep openoffice.org can have a go - on win32, you install msvc stuff all day long) Not to pick nits, but you're not talking about 'Linux', you're talking about Debian... there are other distros you know... ;) In gentoo I know you can have an ebuild that pulls the latest HEAD from whatever repo (or just mirror it locally so you'll always be up to date) and emerge away, but I don't need anything quite that bleeding edge. -- Best regards, Charles -- 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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
Le 2010-10-08 15:07, Scott Furry a écrit : As todd rme has suggested, there exists automated packaging tools. I had not run across that in my readings. I don't use openSUSE, but good to know. My original suggestions regarding a separate repository had been meant to avoid 'package purgatory' where the distributions would relegate LibO to, strictly for example, debian/unstable or debian/experimental. This may preclude the average user from finding and installing LibO to their computer. Even if there are build services available, the suggestion of packaging LibO , even if it was temporary, was to enable LibO availability for the average user. I'm under the assumption that distributions won't pick up LibO just because of what it once was. Sure, other distributions will apply their own stuff to the packaging (Ubuntu being the prime example) but can we put LibO *now* into the hands of the average user? The idea of a distinct and stand-alone updater was to allow for the different use cases with variable distribution/OS platforms, end use environment (single user vs group vs enterprise). The idea is not to build something from scratch, but to pull out the existing updater and make a standalone program. As a standalone program, it can be tweaked/altered/improved without affecting the revision of the main program as a whole. Regards, Scott Furry Yes, this is what I understood from what you meant. Now, to me this makes sense. But is this possible, as you used as an example, the opendesktop.org system? Marc -- 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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On 10/08/2010 06:53 PM, RGB ES wrote: The kind of stuff you find on kde-look.org weights no more than some hundreds of KiB (maybe, a bit more of a MiB but usually a lot less) while a normal LibO install is near 170 MiB... Is the opendesktop.org type proposal for the entire program, or just for the extensions, dictionaries, galleries, extensions, language packs, grammar checkers, and other addons? jonathon -- No human will see non-list, non-bulk, non-junk email sent to this address . It all gets forwarded to /dev/null -- 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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
Thanks. I am a little confused. So are you saying that packaging LibO in such a way as to be able to use the opendesktop.org system is not possible? Everything is possible... but that does not means it is desirable. You always need to use the right tool for the job, and nothing beat a good repository. There are (or were...) attempts to build an easy for the user install and upgrade system (autopackage, zeroinstall...) but almost nobody use those systems. -- 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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
2010/10/8 jonathon jonathon.bl...@gmail.com: Is the opendesktop.org type proposal for the entire program, or just for the extensions, dictionaries, galleries, extensions, language packs, grammar checkers, and other addons? I think people here is talking about the upgrade process. On that case I must say: no, use a good repository instead. But for add-ons it will be perfect. -- 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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
Le 2010-10-08 15:59, RGB ES a écrit : Thanks. I am a little confused. So are you saying that packaging LibO in such a way as to be able to use the opendesktop.org system is not possible? Everything is possible... but that does not means it is desirable. You always need to use the right tool for the job, and nothing beat a good repository. There are (or were...) attempts to build an easy for the user install and upgrade system (autopackage, zeroinstall...) but almost nobody use those systems. Do you know what the reasons were for not using these? It would seem to make sense that you would want to free up dev work and try to unify an upgrade process for everyone. Marc -- 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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
2010/10/8 Marc Paré m...@marcpare.com: Do you know what the reasons were for not using these? It would seem to m ake sense that you would want to free up dev work and try to unify an upgrade process for everyone. Because at the end of the day, they do not work. Just one word: dependencies. If you try to install as user something that needs shared libraries the probability you end with a mess is high: duplicated libraries is just one of the problems, track what is on your system (and clean what is not needed any more) is another. Just look at what happens on windows, with the miracle of the multiplying libraries: windows systems tends to get fatter (and slower, and...) with time just because the install/upgrade system for apps is not centralized. Software repositories managed by system applications (yum, libzipp... whatever) ARE an unified upgrade system, reliable, secure and fast that simplify your life. You just need online storage capacity and someone who build the packages, but that someone do not need to be a developer: almost anyone can build packages (after a period of training, of course ;) ) -- 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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
Le 2010-10-08 16:47, RGB ES a écrit : 2010/10/8 Scott Furryscott.wl.fu...@gmail.com: And that's why I was asking about whether it was possible to have repositories on the documentfoundation.org servers. Users of Debian (and its derivatives) could put apt.documentfoundation.o rg into their sources.list file and there would be a one-stop shop for that distribution to put LibO into users hands. I'm assuming rpm's and other distribution packaging could be setup in a similar fashion. In the same light, Windows users would have a download source for updates. Would this be a security headache? Could this work for the average user? Does this not seem a convenience for the end-user community at large? Others could mirror this repository, but this would be the upstream sour ce for both users/distributions. Are there other factors I'm missing? AFAIK, go-oo people maintained a yum repository. So it is possible. Ok, I unserstand now. Similar to the KDE repos where I got my Mandriva KDE4.5.0 uptade from. They are not maintained by Mandriva but by a KDE packager. Seems to make sense to me. From a marketing point of view, this would be in LibO's interest as the update to LibO would then be a no brainer even from the user point of view. Almost a form of pushing the LibO updates/upgrades through without having to go through distro packaging. In this case, then, it would be a case of having a dedicated dev-packager for each flavour of packaging system used by the distros. Marc -- 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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On 08/10/10 03:06 PM, Marc Paré wrote: I had not heard of Go-OO ( http://go-oo.org ) before until this discussion thread. Visiting their page, it seems like they have the kind of distribution model that we could leverage. Are you talking of the Universal Linux on this page? http://go-oo.org/download/ If so, how would a user be able to add this easily as a repo if he were using a system such as Mageia (Mandriva) as I am using? (Just as an example.) I was actually commenting on the delivery as a whole and not on any specific features. Sure they have Universal Linux, but cater to a larger crowd with different distributions. Windows, MacOSX, et al can download from one place. Not sure what patches the downstream distributions have picked up, but this group appears (on the surface) to have the kind of distribution being discussed. -- 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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On Fri, Oct 8, 2010 at 4:53 PM, Marc Paré m...@marcpare.com wrote: Le 2010-10-08 16:47, RGB ES a écrit : 2010/10/8 Scott Furryscott.wl.fu...@gmail.com: And that's why I was asking about whether it was possible to have repositories on the documentfoundation.org servers. Users of Debian (and its derivatives) could put apt.documentfoundation .o rg into their sources.list file and there would be a one-stop shop for tha t distribution to put LibO into users hands. I'm assuming rpm's and other distribution packaging could be setup in a similar fashion. In the same light, Windows users would have a download source for updates. Would this be a security headache? Could this work for the average user? Does this not seem a convenience for the end-user community at large? Others could mirror this repository, but this would be the upstream so ur ce for both users/distributions. Are there other factors I'm missing? AFAIK, go-oo people maintained a yum repository. So it is possible. Ok, I unserstand now. Similar to the KDE repos where I got my Mandriva KDE4.5.0 uptade from. They are not maintained by Mandriva but by a KDE packager. Seems to make sense to me. From a marketing point of view, this would be in LibO's interest as the update to LibO would then be a no brainer even from the user point of vie w. Almost a form of pushing the LibO updates/upgrades through without havi ng to go through distro packaging. In this case, then, it would be a case of having a dedicated dev-packager for each flavour of packaging system used by the distros. Marc You wouldn't necessary need one person for each packaging system. As I pointed out earlier, the opensuse buildservice makes it easier to automatically build packages for many distributions at once. It automates much of the process, including setting up the build environment, pulling in dependencies, building, pushing the builds to servers, and automatically rebuilding after changes in upstream packages. You still need to set up the rpm spec file and whatever the equivalent is for deb files (although you should only need one of each total), but that is a lot easier than handling individual build environments and servers for each distribution by hand. It doesn't support all distributions, I know off the top of my head that Arch and Gentoo are not supported and I am sure there are many more, but it does handle at least Ubuntu, openSUSE/SLE, Fedora/Redhat/CentOS, and mandriva. -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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On Fri, Oct 8, 2010 at 5:46 PM, Marc Paré m...@marcpare.com wrote: Le 2010-10-08 17:22, todd rme a écrit : On Fri, Oct 8, 2010 at 4:53 PM, Marc Parém...@marcpare.com wrote: Le 2010-10-08 16:47, RGB ES a écrit : 2010/10/8 Scott Furryscott.wl.fu...@gmail.com: And that's why I was asking about whether it was possible to have repositories on the documentfoundation.org servers. Users of Debian (and its derivatives) could put apt.documentfoundati on .o rg into their sources.list file and there would be a one-stop shop for t ha t distribution to put LibO into users hands. I'm assuming rpm's and oth er distribution packaging could be setup in a similar fashion. In the sa me light, Windows users would have a download source for updates. Would this be a security headache? Could this work for the average user? Does this not seem a convenience for the end-user community at large? Others could mirror this repository, but this would be the upstream so ur ce for both users/distributions. Are there other factors I'm missing? AFAIK, go-oo people maintained a yum repository. So it is possible. Ok, I unserstand now. Similar to the KDE repos where I got my Mandriva KDE4.5.0 uptade from. They are not maintained by Mandriva but by a KDE packager. Seems to make sense to me. From a marketing point of view, this would be in LibO's interest as the update to LibO would then be a no brainer even from the user point of v ie w. Almost a form of pushing the LibO updates/upgrades through without ha vi ng to go through distro packaging. In this case, then, it would be a case of having a dedicated dev-packag er for each flavour of packaging system used by the distros. Marc You wouldn't necessary need one person for each packaging system. As I pointed out earlier, the opensuse buildservice makes it easier to automatically build packages for many distributions at once. It automates much of the process, including setting up the build environment, pulling in dependencies, building, pushing the builds to servers, and automatically rebuilding after changes in upstream packages. You still need to set up the rpm spec file and whatever the equivalent is for deb files (although you should only need one of each total), but that is a lot easier than handling individual build environments and servers for each distribution by hand. It doesn't support all distributions, I know off the top of my head that Arch and Gentoo are not supported and I am sure there are many more, but it does handle at least Ubuntu, openSUSE/SLE, Fedora/Redhat/CentOS, and mandriva. -Todd Would you then have any idea if this would cause a lot of devoted dev tim e, part-time, full-time attention. Would LibO then have to have a dedicated dev in charge of this? Marc I doubt it would require a full-time developer, since changes would only need to be made when a new version of openoffice or, maybe, when a new version of a distribution is released, so probably 4 or 5 times a year. I don't know about deb files, but spec files for rpms would only require the version number be changed and, if there are changes to the file names in output, some changes to the list of files. We are probably talking a few hundred lines of code for the entire spec file, and only between 1 and maybe a few dozen would have to be changed for a openoffice update, while only at most 5 or so would likely need to be changed for a new distribution release (ideally none would have to be changed in that case). However, it may still be too much work given the benefit. Distributions will normally handle the packaging themselves anyway, so I am not exactly clear on what benefit there would be in duplicating this effort. Really the main benefit I can see is not to users directly, it is making sure the software builds on common Linux distributions without distributions having to make their own modifications. So it may be worthwhile from a debugging perspective alone, and if the packages are going to be built then publishing them would be no added effort. -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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
Would you then have any idea if this would cause a lot of devoted dev tim e, part-time, full-time attention. Would LibO then have to have a dedicated dev in charge of this? Marc I doubt it would require a full-time developer, since changes would only need to be made when a new version of openoffice or, maybe, when a new version of a distribution is released, so probably 4 or 5 times a year. I don't know about deb files, but spec files for rpms would only require the version number be changed and, if there are changes to the file names in output, some changes to the list of files. We are probably talking a few hundred lines of code for the entire spec file, and only between 1 and maybe a few dozen would have to be changed for a openoffice update, while only at most 5 or so would likely need to be changed for a new distribution release (ideally none would have to be changed in that case). However, it may still be too much work given the benefit. Distributions will normally handle the packaging themselves anyway, so I am not exactly clear on what benefit there would be in duplicating this effort. Really the main benefit I can see is not to users directly, it is making sure the software builds on common Linux distributions without distributions having to make their own modifications. So it may be worthwhile from a debugging perspective alone, and if the packages are going to be built then publishing them would be no added effort. -Todd Perhaps a benefit would be a coordinated unveiling of the product on a given date. Rather than having to rely on other distros to update their packaging, DocumentFoundation would then be the distributor of the different packages. Updates and critical bug fixes could then be distributed quicker. Marc -- 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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On Fri, Oct 8, 2010 at 10:50 PM, Marc Paré m...@marcpare.com wrote: Would you then have any idea if this would cause a lot of devoted dev t im e, part-time, full-time attention. Would LibO then have to have a dedicate d dev in charge of this? Marc I doubt it would require a full-time developer, since changes would only need to be made when a new version of openoffice or, maybe, when a new version of a distribution is released, so probably 4 or 5 times a year. I don't know about deb files, but spec files for rpms would only require the version number be changed and, if there are changes to the file names in output, some changes to the list of files. We are probably talking a few hundred lines of code for the entire spec file, and only between 1 and maybe a few dozen would have to be changed for a openoffice update, while only at most 5 or so would likely need to be changed for a new distribution release (ideally none would have to be changed in that case). However, it may still be too much work given the benefit. Distributions will normally handle the packaging themselves anyway, so I am not exactly clear on what benefit there would be in duplicating this effort. Really the main benefit I can see is not to users directly, it is making sure the software builds on common Linux distributions without distributions having to make their own modifications. So it may be worthwhile from a debugging perspective alone, and if the packages are going to be built then publishing them would be no added effort. -Todd Perhaps a benefit would be a coordinated unveiling of the product on a gi ven date. Rather than having to rely on other distros to update their packagi ng, DocumentFoundation would then be the distributor of the different package s. Updates and critical bug fixes could then be distributed quicker. Marc But it is important to keep in mind the distributions' own release policies. Many distributions do not allow non-security-related updates over the course of a single release cycle. This allows them to thoroughly test a given combination of software. Having the distribution release one set of packages and having the foundation release another set may be confusing to users and will may prove to be a major annoyance to distributions which work hard to provide a coherent set of packages. I am not saying that such packages should not be released, my point is merely that we need to be mindful of the needs and limitations of the distribution maintainers, and not make life any more difficult for them than is absolutely necessary. Just pushing out packages and telling users to download them is not a good strategy, in fact it is a really good way to turn distributions against you. More thought, and a lot of discussion with those maintaining the distributions, will be needed in order to guarantee a mutually beneficial approach. It may not be possible to completely please every party, but unilaterally bypassing the distributions entirely is not a good idea in my opinion. -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/
Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)
On Sat, Oct 9, 2010 at 12:42 AM, Marc Paré m...@marcpare.com wrote: But it is important to keep in mind the distributions' own release policies. Many distributions do not allow non-security-related updates over the course of a single release cycle. This allows them to thoroughly test a given combination of software. Having the distribution release one set of packages and having the foundation release another set may be confusing to users and will may prove to be a major annoyance to distributions which work hard to provide a coherent set of packages. I am not saying that such packages should not be released, my point is merely that we need to be mindful of the needs and limitations of the distribution maintainers, and not make life any more difficult for them than is absolutely necessary. Just pushing out packages and telling users to download them is not a good strategy, in fact it is a really good way to turn distributions against you. More thought, and a lot of discussion with those maintaining the distributions, will be needed in order to guarantee a mutually beneficial approach. It may not be possible to completely please every party, but unilaterally bypassing the distributions entirely is not a good idea in my opinion. -Todd Yes, you are right. But in this case the service would be offered to them and it would be up to the distros to either use it or not. Or the user of that particular distro would then have the option of installing it if wished. And if they refuse, would you still release the packages anyway? This is what the KDE group offer. I got my updates to KDE4.5.0 from the K DE site rather than wait for the Mandriva repos update, which of course are on hold now. I just set up my package manager to point to the KDE repos for Mandriva. This method seems to work well for the KDE group. KDE does not offer binaries as a rule. There are Mandriva binaries on the KDE ftp server, but that is the only distribution that has binaries on the KDE server. Further, I do not think that those are actually produced by KDE itself, KDE was simply nice enough to host them. In fact several people, myself included, have suggested to KDE developers that they release official binaries and they refused, saying that it was the responsibility of the distributions to produce the binaries. -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/
Re: [tdf-discuss] Automatic Updates
On 2010-10-06 6:43 PM, Jon Hamkins wrote: Then installations and updates can be as simple as # yum install libreoffice and # yum update libreoffice I like it... :) -- Best regards, Charles -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
On 2010-10-06 7:00 PM, Jon Hamkins wrote: The way this works is LibO would publish delta RPMs that contain all the differences from the previous release, and then the users yum package manager would download the delta RPM, build the full RPM from it, and install. Excellent points, and there's the rub. OOo has never (at least to my knowledge) provided delta updates of any kind. So the key will be providing this mechanism on the back-end, then just publish instructions for the different platforms/package managers. And since Windows is the only one of those platforms that doesn't have a proper package manager, the current internal 'updater' could become a Windows-only true 'Updater'. -- Best regards, Charles -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
On 2010-10-06 7:54 PM, Marc Paré wrote: If there were a common method to do incremental updates (linux) to avoid too much work from the devs, this would be great. Judging by the discussions, it looks like it could be a challenge though. I disagree... the way I see it working is: 1. The devs provide one standard 'diff' file for any/all platforms to use - it would be up to the individual packagers to take that diff and apply it according to the standards imposed by their package management system. 2. The current 'internal' 'updater' (which is more like a notifier and download manager now) could become a Windows-only true 'Updater' that applies the diff in the 'Windows way' (just please don't make a system reboot a requirement)... -- Best regards, Charles -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
Hi Scott, Thanks for the insightful comments... On 2010-10-06 5:21 PM, Scott Furry wrote: a) AFAIK, MSIEXEC doesn't enforce any kind of standards/best practices. I'm not sure I see your point. That doesn't mean that whoever codes the .msi installer cannot code it to work as I have described. Yes, it means they will actually have to tell msiexec precisely what to do, but is that really all that bad of a thing? But ... (see below) Sure it does a lovely job of unpacking things and installing, but so do a lot of other 3rd party installer programs (NSIS, IzPack, Bitrock, et al.). If it will work better, and more importantly, be easier for the devs to accomplish the goal of incremental updates, I'm all for it. One caveat though - .msi installers are required (I think) if you want to incorporate GPO (Group Policies in windows domains) support, and that is something else that I'd dearly love to see. Can these 3rd party tools generate .msi files, or at least installers that will work with GPO? Where these windows-based installers fail is that they do not guide or enforce a standard install methodology. While I agree it would be nice if they did, all that would effectively mean is less work for the people writing their .msi installers (they could use internal calls/routines and not worry about where to put stuff, performing clean-up, etc). Case in point is that the install path can be defined to whatever your heart desires. Sure you can use a predefined value to fill this variable (e.g. %programfiles%, %homedir%, etc), but there is no direction in the documentation as to what/where is the correct/best place - just suggestions. MSIEXEC is a means to an end - install methodology. All true - but again, I don't see anything that prevents whoever is writing the .msi to do so successfully and in such a manner as it will work reliably in all Windows environments. Which leads to... b) In my original post I mentioned that any install should respect the package management of the base operating system. I still agree with this notion. And unfortunately, Mozilla breaks this mold. *nix users will run into permission issues if they try to update Firefox and/or Thunderbird from the program menus. Even Ubuntuzilla (a command line python script to perform updates) is external to Mozilla and needs permissions to perform an update. I agree an incremental update is a good idea, but to emulate these two programs I suggest is not the shining example of 'best of bread'. I agree, but the problem here is that the individual package managers should be *disabling* the internal updaters in their packages, so that they can only be updated using the package management system. This way the internal updater would only work for someone who installed from source, and whether or not it works properly would depend on the one who installed it installing it in a location where the app has the appropriate permissions and can successfully update itself. The reason I object is that I have run into instances where entities external to Mozilla would hijack the install function placing plugins into the framework that the user either has no knowledge of and/or the installed code can only be removed through extraordinary measures (deleting from the command line/file manager). Lovely thought, but security becomes a major issue if we go this route. There must be a certain level of trust where package managers are concerned. If a packager does something stupid like this, then that systems users to scream bloody hell. The responsibility of the LibO devs would end at simply providing the standardized diff. This would not be an issue for anyone installing the official LibO app, since the LibO devs would have full control of the process, both install and updates. Package management (i.e. such as apt, yum, rpm, etc) means the download is coming from a well defined location (you can trace the source) and is put into a specific format (deb, rpm, et al). Security is a factor in these methodologies and you can reinstall, remove/purge the package through the command line or GUI. Incremental updates are apart of this function. Fine, so use them... my main point was incremental updates, not doing it using the application updater (guess I could have been more clear on this point). OOo, and post-divergence - LibO, has an internal mechanism for updating extensions and itself. But this leads invariably to the situation I described above with Mozilla. Security and User Permissions then become serious factors. I agree that a better job of identifying an existing install and clean up is necessary. Windows becomes the corner case... Fine, let it be the corner case where the internal updater is used. The mozilla auto-updaters work *great* on Windows, so the LibO auto-updater should be able to do the same (if coded properly). There is no defined standard of where to install files, just suggestions. And an update
Re: [tdf-discuss] Automatic Updates
On 2010-10-07 9:15 AM, Charles Marcus wrote: I agree, but the problem here is that the individual package managers should be *disabling* the internal updaters in their packages, so that they can only be updated using the package management system. And Mozilla should provide a simple compile switch that can be invoked to accomplish this (maybe they do already?). -- Best regards, Charles -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
On Fri, Oct 8, 2010 at 12:04 AM, Per Eriksson pereriks...@openoffice.orgw
rote:
I am not sure if Mozilla offer out-of-the-box updating for Firefox on
Linux?
Yes,
Firefox, ThunderBird has options (which are turned on by default)
that let you choose whether to set them automatically (or manually) update
Firefox/Thunderbird, add-on and search engines.
--
Best Regards,
Nguyen Hung Vu [aka: NVH] ( in Vietnamese: Nguyễn Vũ Hưng
)
vuhung16plus{remo...@gmail.dot.com
vuhung16plus%7bremove...@gmail.dot.com, YIM: vuhung16 , Skype:
vuhung16plus
A brief profile: http://www.hn.is.uec.ac.jp/~vuhung/Nguyen.Vu.Hung.html
--
To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
On Thu, Oct 7, 2010 at 4:27 AM, Michele Zarri m.za...@gmail.com wrote:
On 06/10/10 22:21, Jean Hollis Weber wrote:
On Wed, 2010-10-06 at 14:21 -0400, Charles Marcus wrote:
On 2010-10-06 2:06 PM, Charles Marcus wrote:
Yes there is... use the MSI system, which will take care of things lik
e
unpacking to the environments /tmp directory, launching the installer
after unpacking (like it does now), then - and here is the trickey par
t
I guess - detect a current installation, and offer to upgrade it, or t
o
install a parallel version.
Oh - and one thing that I'd really like to see is a simple 'incremental
updater' that just downloads a 'patch' file and patches itself, like
Firefox and Thunderbird and lots of other programs do now.
+10
--Jean
+1
+1.
And for Mac OS X, as it doesn't (?) have a package management system,
we can leave the update agent as it is.
--
Best Regards,
Nguyen Hung Vu [aka: NVH] ( in Vietnamese: Nguyễn Vũ Hưng
)
vuhung16plus{remo...@gmail.dot.com
vuhung16plus%7bremove...@gmail.dot.com, YIM: vuhung16 , Skype:
vuhung16plus
A brief profile: http://www.hn.is.uec.ac.jp/~vuhung/Nguyen.Vu.Hung.html
--
To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
Hi Per, *, Per Eriksson schrieb: [..] I am not sure if Mozilla offer out-of-the-box updating for Firefox on Linux? You have to fetch the linux file from Mozilla and unpack it in a folder where you have write permissions. Call it, use it, update it, - be happy :o)) Gruß/regards -- Friedrich Ansprechpartner / contact person for the PrOOo-Box german language best Office Suite ever and more on CD/DVD http://prooo-box.org -- footer changed on 2010-10-07 -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
Hi, Do we have skilled people here who are interested in beginning with this effort, and maybe start planning for this feature? I've always been interested in pushing things like this forward ;-) Best Per Friedrich Strohmaier skrev 2010-10-07 21:29: Hi Per, *, Per Eriksson schrieb: [..] I am not sure if Mozilla offer out-of-the-box updating for Firefox on Linux? You have to fetch the linux file from Mozilla and unpack it in a folder where you have write permissions. Call it, use it, update it, - be happy :o)) Gruß/regards -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
Op 6/10/2010 20:59, Per Eriksson schreef: Hi, Marc Paré skrev 2010-10-06 20:39: Le 2010-10-06 14:30, Steven Shelton a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/6/2010 2:21 PM, Charles Marcus wrote: Oh - and one thing that I'd really like to see is a simple 'incremental updater' that just downloads a 'patch' file and patches itself, like Firefox and Thunderbird and lots of other programs do now I would vote for this too. It would be amazing if it were capable. Marc +1 Tell me how I can help. Best Per +1 Leo -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
Quote attributions got messed up - sorry... Again, I have to go back to my earlier posts - Mozilla is not the shinning example. Their incremental updater works very well on Windows - and with the Update Notifier extension, all updates can be made pretty much silent and automatic. For any Firefox user, type about:plugins into your search bar and see what comes back. You will find that MS has (more often through Windows Update) installed ActiveX, Eh? ActiveX in Firefox? Methinks you typed without thinking... ;) Silverlight, .Net Framework plugins all without the users knowledge and consent. Even Java has this behavior on Windows (*nix requires a separate package). And you can't scream if you don't know its being done. There were some noises on forums when this first came to light, but the average user ether doesn't know or doesn't care that some other company is forcing their will on how your browser behaves. I agree, but the problem here is that the individual package managers should be *disabling* the internal updaters in their packages, so that they can only be updated using the package management system. And Mozilla should provide a simple compile switch that can be invoked to accomplish this (maybe they do already?). This is accomplished through user permissions. Is the person root? no - disable menu updates I don't think this should be relied on. For one thing, if the app is installed in /usr/local, root perms should not be needed to update it. And above you said yourself that the *package managers* should be disabling it... so, again, this should be a packaging/compile flag, so the admin of the box can decide which updater to use. I have no insight on Group Policies. A look through their documentation should give you the answer. According to the mozilla devs, who are working toward supporting GPO right now, .msi files are needed, but they can be built using 3rd party non MS tools... my main point was incremental updates, not doing it using the application updater (guess I could have been more clear on this point). We do use them. I just wish we had people who specialize in this capability. Eh? I have never seen an 'updater', incremental or otherwise... when/where have updaters ever been provided?? If there were 'package specialists', the burden of distribution/updating could be unloaded from the LibO dev community. There are - they work for the individual distros, and all LibreOffice has to do to take advantage of them is simply provide two standard packages for installation - a full package (could be in the form of a .tar.gz, or whatever makes sense), and an incremental updater (in the form of a .diff for *nix, and both full and patch .msi files for windows. Maybe what is needed is some simple communication to the major distros to see what form would be best. I cannot imagine this would be that difficult - they should all be able to work with standard tarballs and do whatever is needed on their end to make it work. From all the discussions so far, we have three criteria for Windows installs: - clean up after itself - update (uninstall previous installation) - Group Policy installs/configuration Sound about right? And a wish for an Incremental Update Mechanism similar in nature to what Mozilla offers. Yes, sounds about right... the native incremental update would be mainly for 'home' type users, and the .msi/gpo updates would be for corporate environments making use of GPO for managing their software. Also, the use of tar.gz, tar.bz2 or zip should be IMHO reserved for source file distribution. Okay... but for a package as large as LibreOffice, it seems to me that a .diff approach would be much better... the only time it wouldn't be practical is for major updates (ie, going from 2.0.1 to 3.3)... but code the update routine to check for that and just download the new version, uninstall the old version and install the new version. And as I mentioned earlier, we should look at engaging 'package specialists' - people who can alleviate some of the burden from devs about distribution. Am I missing anything from the discussions? No, that covers it. I wish I were a programmer so I could help with the heavy lifting, but I'm not... -- Best regards, Charles -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
On 07/10/10 03:04 PM, Charles Marcus wrote: Again, I have to go back to my earlier posts - Mozilla is not the shinning example. Their incremental updater works very well on Windows - and with the Update Notifier extension, all updates can be made pretty much silent and automatic. True enough. But this feature is not available to non-root users on *nix. For any Firefox user, type about:plugins into your search bar and see what comes back. You will find that MS has (more often through Windows Update) installed ActiveX, Eh? ActiveX in Firefox? Methinks you typed without thinking... ;) Silverlight, .Net Framework plugins all without the users knowledge and consent. Even Java has this behavior on Windows (*nix requires a separate package). And you can't scream if you don't know its being done. There were some noises on forums when this first came to light, but the average user ether doesn't know or doesn't care that some other company is forcing their will on how your browser behaves. Not a typo. Not everyone has coughed up to get the latest/greatest according to Redmond. Yes, its disused and out of favor, but WinXP users would still see the plugin installed. Again, I dislike the idea of silently dumping some feature into a program path because they think they know better. The user should have control over their install. (Enterprise installs open a very different use case). I agree, but the problem here is that the individual package managers should be *disabling* the internal updaters in their packages, so that they can only be updated using the package management system. And Mozilla should provide a simple compile switch that can be invoked to accomplish this (maybe they do already?). This is a problem. Why should package managers dig into the code to disable something? This is accomplished through user permissions. Is the person root? no - disable menu updates I don't think this should be relied on. For one thing, if the app is installed in /usr/local, root perms should not be needed to update it. And on *nix, root(or superuser) is required. You are either root or on the sudoer list. Can't get away from that. On many computer operating systems, the *superuser*, or *root*, is a special user account used for system administration. Separation of administrative privileges from normal user privileges makes an operating system more resistant to viruses and other malware. Additionally, in organizations, administrative privileges are often reserved for authorized individuals in order to control abuse, misuse, or other undesired activities by end-users. http://en.wikipedia.org/wiki/Root_user And above you said yourself that the *package managers* should be disabling it... so, again, this should be a packaging/compile flag, so the admin of the box can decide which updater to use. That's your quote, not mine. I agree that the functionality should be disabled, but package management involves strictly 'packaging' for a distribution. This may involve compiling the code. And as you suggested a compile switch could be used. I have no insight on Group Policies. A look through their documentation should give you the answer. According to the mozilla devs, who are working toward supporting GPO right now, .msi files are needed, but they can be built using 3rd party non MS tools... Sounds like GPO (or enterprise installs) should be looked as a separate usability case once the dust settles here. my main point was incremental updates, not doing it using the application updater (guess I could have been more clear on this point). We do use them. I just wish we had people who specialize in this capability. Eh? I have never seen an 'updater', incremental or otherwise... when/where have updaters ever been provided?? That's the purpose of package management programs (apt, dpkg, yum, rpm, etc.). What is Apt? Apt /(for *A*dvanced *P*ackage *T*ool)/ is a set of core tools inside Debian. Apt makes it possible to: * Install applications * Remove applications * Keep your applications up to date * And much more... Quoted from http://wiki.debian.org/Apt Just one example of many in the *nix world. If there were 'package specialists', the burden of distribution/updating could be unloaded from the LibO dev community. There are - they work for the individual distros, and all LibreOffice has to do to take advantage of them is simply provide two standard packages for installation - a full package (could be in the form of a .tar.gz, or whatever makes sense), and an incremental updater (in the form of a .diff for *nix, and both full and patch .msi files for windows. Maybe what is needed is some simple communication to the major distros to see what form would be best. I cannot imagine this would be that difficult - they should all be able to work with standard tarballs and do whatever is needed on their end to make it work. Not all of them. Case in point is the person who put
Re: [tdf-discuss] Automatic Updates
On 2010-10-07 6:05 PM, Scott Furry wrote: On 07/10/10 03:04 PM, Charles Marcus wrote: Their incremental updater works very well on Windows - and with the Update Notifier extension, all updates can be made pretty much silent and automatic. True enough. But this feature is not available to non-root users on *nix. Why not? If the software is installed somewhere that does not require root permissions, why would root perms be needed to update it? Makes no sense. *nix is perfectly capable of allowing normal users to install software. For any Firefox user, type about:plugins into your search bar and see what comes back. You will find that MS has (more often through Windows Update) installed ActiveX, Eh? ActiveX in Firefox? Methinks you typed without thinking... ;) Yes, its disused and out of favor, but WinXP users would still see the plugin installed. No, they wouldn't (in the case of ActiveX) - since apparently you missed my point that there is no ActiveX for Firefox - never has been, never will be (unless someone pony's up a bunch of cash). Again, I dislike the idea of silently dumping some feature into a program path because they think they know better. The user should have control over their install. (Enterprise installs open a very different use case). I agree - but the one (ActiveX) has nothing to do with the other (Microsoft silently installing .net extensions)... This is a problem. Why should package managers dig into the code to disable something? ?? They don't have to 'dig into the code' to flip compile switches for specific packages - they do that all the time (some packages are built with SSL support, some aren't, etc). And on *nix, root(or superuser) is required. You are either root or on the sudoer list. Can't get away from that. My understanding is this is only true if you're installing something for everyone. If you're installing something only for yourself - ie, like I said earlier, in /usr/local, or even in /home/user/apps - then I am fairly certain that root is *not* required... Am I wrong? On many computer operating systems, the *superuser*, or *root*, is a special user account used for system administration. sigh I know what root is. And above you said yourself that the *package managers* should be disabling it... so, again, this should be a packaging/compile flag, so the admin of the box can decide which updater to use. That's your quote, not mine. My bad - I forgot I had replied to myself... apologies... Sounds like GPO (or enterprise installs) should be looked as a separate usability case once the dust settles here. No doubt... Eh? I have never seen an 'updater', incremental or otherwise... when/where have updaters ever been provided? That's the purpose of package management programs (apt, dpkg, yum, rpm, etc.). I was speaking to an updater for Windows... there never has been one. Maybe what is needed is some simple communication to the major distros to see what form would be best. I cannot imagine this would be that difficult - they should all be able to work with standard tarballs and do whatever is needed on their end to make it work. Not all of them. Case in point is the person who put together the Debian packages (Nikola Yanev - great work BTW :D ). There are others out there in the community. It would be great if they (and their skills) could be be brought together allowing for a one-stop-download location of packages for the different OS distributions. This would then be considered the upstream repository from which the various OS distribution teams could then mirror/pull down LibO for distribution to users of that OS. I do not think that LibO should be in the business of providing individual distro packages - let the distro package managers do that. It will free up lots of developer resources to focus on programming, not building/providing packages. Okay... but for a package as large as LibreOffice, it seems to me that a .diff approach would be much better... the only time it wouldn't be practical is for major updates (ie, going from 2.0.1 to 3.3)... but code the update routine to check for that and just download the new version, uninstall the old version and install the new version. Again...a package is supplied in a compressed archive format, albeit with a different extension. sigh so compress it. Debian packages are standard Unix ar archives that include two gzipped, bzipped or lzmaed tar archives: one that holds the control information and another that contains the data. Yes, and the deb package maintainers generally pull *the source* from the source provider (in this case, the LibO repositories), then builds their packages. Again - let the distro package maintainers do the heavy lifting there... all LibO needs to do is provide access to the source. Maybe one problem in our communication here is you seem to be focused on the historical process of the OOo community has always
Re: [tdf-discuss] Automatic Updates
On 07/10/10 05:00 PM, Charles Marcus wrote: On 2010-10-07 6:05 PM, Scott Furry wrote: On 07/10/10 03:04 PM, Charles Marcus wrote: Their incremental updater works very well on Windows - and with the Update Notifier extension, all updates can be made pretty much silent and automatic. True enough. But this feature is not available to non-root users on *nix. Why not? If the software is installed somewhere that does not require root permissions, why would root perms be needed to update it? Makes no sense. *nix is perfectly capable of allowing normal users to install software. For a local user only in there own directory, ok. For any Firefox user, type about:plugins into your search bar and see what comes back. You will find that MS has (more often through Windows Update) installed ActiveX, Eh? ActiveX in Firefox? Methinks you typed without thinking... ;) Yes, its disused and out of favor, but WinXP users would still see the plugin installed. No, they wouldn't (in the case of ActiveX) - since apparently you missed my point that there is no ActiveX for Firefox - never has been, never will be (unless someone pony's up a bunch of cash). I have seen an ActiveX plugin installed in Firefox (which I promptly removed). A quick google search shows that: a) Mozilla doesn't support it (no surprise) - http://support.mozilla.com/en-US/kb/activex b) there are others who have created add-ins/plugins for firefox (why is beyond me) ...but the one (ActiveX) has nothing to do with the other (Microsoft silently installing .net extensions)... Agree to disagree... But we are agreed that its bad to silently push plugins/software/extensions/insert name onto an application without the user knowing what to expect. Regardless of the examples...its just bad. Right? This is a problem. Why should package managers dig into the code to disable something? ?? They don't have to 'dig into the code' to flip compile switches for specific packages - they do that all the time (some packages are built with SSL support, some aren't, etc). Agreed. Your previous text led me to believe you were suggesting that the person doing the packaging was to edit the source code. This person doesn't have a need to open up and/or change source code. And on *nix, root(or superuser) is required. You are either root or on the sudoer list. Can't get away from that. My understanding is this is only true if you're installing something for everyone. If you're installing something only for yourself - ie, like I said earlier, in /usr/local, or even in /home/user/apps - then I am fairly certain that root is *not* required... Am I wrong? No. Your not wrong. But installing locally is usually done either for development purposes or some other very-special need. Package installations do not install for local use only as that is not the recommend methodology. My bad - I forgot I had replied to myself... apologies... No worries. :) Sounds like GPO (or enterprise installs) should be looked as a separate usability case once the dust settles here. No doubt... I sense a task force would be useful to resolve this issue (not as grand as the IETF mind you). Just a few select people to document the use cases, identify risks/roadblocks, detail requirements...usual project management. Eh? I have never seen an 'updater', incremental or otherwise... when/where have updaters ever been provided? That's the purpose of package management programs (apt, dpkg, yum, rpm, etc.). I was speaking to an updater for Windows... there never has been one. What about Windows Update? From a non-os software side, I do recall seeing a update/notify program. Can't remember the name and I no longer can find the link. Maybe what is needed is some simple communication to the major distros to see what form would be best. I cannot imagine this would be that difficult - they should all be able to work with standard tarballs and do whatever is needed on their end to make it work. Not all of them. Case in point is the person who put together the Debian packages (Nikola Yanev - great work BTW :D ). There are others out there in the community. It would be great if they (and their skills) could be be brought together allowing for a one-stop-download location of packages for the different OS distributions. This would then be considered the upstream repository from which the various OS distribution teams could then mirror/pull down LibO for distribution to users of that OS. I do not think that LibO should be in the business of providing individual distro packages - let the distro package managers do that. It will free up lots of developer resources to focus on programming, not building/providing packages. The Debian distribution has over 25,000 different packages in their repository. You think Debian has the time to look after this stuff? Especially since its staffed with volunteers around the globe? If somebody from the organization and/or community does not do the
Re: [tdf-discuss] Automatic Updates
On 2010-10-06 1:04 AM, Scott Furry wrote: Any installation method that is deployed, in my mind, must 'respect' the package management of the base operating system. +1 - So, for most *nix's, this would mean that the built-in LibO updater should be disabled, and let the systems package manager take care of it. Problem is that Windows doesn't have a package management system. There is no one simple way to install, update or uninstall. Yes there is... use the MSI system, which will take care of things like unpacking to the environments /tmp directory, launching the installer after unpacking (like it does now), then - and here is the trickey part I guess - detect a current installation, and offer to upgrade it, or to install a parallel version. I am not a programmer, but I know enough about it to know that this wouldn't be all that difficult to do for a good programmer who has experience writing installer scripts for the windows platform. Yes, there is msiexec, but that just provides a means to an end and doesn't handle update mechanisms nor framework/standardize installs. As for update mechanisms, we're left with 3rd party programs. The current OOo auto-update detector would be fine if the update process itself worked as I described above. Other than making sure that LibO cleans up after itself, how much effort do we want to put into installers? Since updates is one of the things that seems to confuse a lot of people, I think it would be a good thing if this could be fixed... Oh - and while we're on the subject, please, bring back the ability to choose how File Associations are configured in the GUI installer - but with the addition of the new XML versions too (so, there would be 6 checkbox/choices instead of just 3. -- Best regards, Charles -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/6/2010 2:21 PM, Charles Marcus wrote: Oh - and one thing that I'd really like to see is a simple 'incremental updater' that just downloads a 'patch' file and patches itself, like Firefox and Thunderbird and lots of other programs do now +1 - -- Steven Shelton Deputy Undersecretary for Made-up Titles -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyswC4ACgkQO+AD2HqgRoB0tgCgrLE++fnRuftt7I7UewR7xthz s4QAn26yIA9YQqqoLfyJlRUkmUSVLK03 =BaN+ -END PGP SIGNATURE- -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
Le 2010-10-06 14:30, Steven Shelton a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/6/2010 2:21 PM, Charles Marcus wrote: Oh - and one thing that I'd really like to see is a simple 'incremental updater' that just downloads a 'patch' file and patches itself, like Firefox and Thunderbird and lots of other programs do now I would vote for this too. It would be amazing if it were capable. Marc -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
On 06/10/10 12:21 PM, Charles Marcus wrote: On 2010-10-06 2:06 PM, Charles Marcus wrote: Yes there is... use the MSI system, which will take care of things like unpacking to the environments /tmp directory, launching the installer after unpacking (like it does now), then - and here is the trickey part I guess - detect a current installation, and offer to upgrade it, or to install a parallel version. Oh - and one thing that I'd really like to see is a simple 'incremental updater' that just downloads a 'patch' file and patches itself, like Firefox and Thunderbird and lots of other programs do now. Charles, For the most part I agree with you. Where, I have a problem is with: a) what MSIEXEC does b) purpose/function of incremental updates a) AFAIK, MSIEXEC doesn't enforce any kind of standards/best practices. Sure it does a lovely job of unpacking things and installing, but so do a lot of other 3rd party installer programs (NSIS, IzPack, Bitrock, et al.). Where these windows-based installers fail is that they do not guide or enforce a standard install methodology. Case in point is that the install path can be defined to whatever your heart desires. Sure you can use a predefined value to fill this variable (e.g. %programfiles%, %homedir%, etc), but there is no direction in the documentation as to what/where is the correct/best place - just suggestions. MSIEXEC is a means to an end - install methodology. Granted, how LibO uses the windows install is put into question. And I agree, we(community plural) should be doing a better job. I know of other programs whose installers ask if you want to remove the previous installation. So it is possible. The capabilities are there to install/uninstall, but the update mechanism is up for grabs as several programs each have their own ideas about how to scan the WWW for and incorporate updates. Which leads to... b) In my original post I mentioned that any install should respect the package management of the base operating system. I still agree with this notion. And unfortunately, Mozilla breaks this mold. *nix users will run into permission issues if they try to update Firefox and/or Thunderbird from the program menus. Even Ubuntuzilla (a command line python script to perform updates) is external to Mozilla and needs permissions to perform an update. I agree an incremental update is a good idea, but to emulate these two programs I suggest is not the shining example of 'best of bread'. The reason I object is that I have run into instances where entities external to Mozilla would hijack the install function placing plugins into the framework that the user either has no knowledge of and/or the installed code can only be removed through extraordinary measures (deleting from the command line/file manager). Lovely thought, but security becomes a major issue if we go this route. Package management (i.e. such as apt, yum, rpm, etc) means the download is coming from a well defined location (you can trace the source) and is put into a specific format (deb, rpm, et al). Security is a factor in these methodologies and you can reinstall, remove/purge the package through the command line or GUI. Incremental updates are apart of this function. OOo, and post-divergence - LibO, has an internal mechanism for updating extensions and itself. But this leads invariably to the situation I described above with Mozilla. Security and User Permissions then become serious factors. I agree that a better job of identifying an existing install and clean up is necessary. Windows becomes the corner case... There is no defined standard of where to install files, just suggestions. And an update mechanism becomes an external program. There are 3rd party apps for updating sources. I believe we should explore those options. Regards, Scott Furry -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
On 06/10/10 22:21, Jean Hollis Weber wrote: On Wed, 2010-10-06 at 14:21 -0400, Charles Marcus wrote: On 2010-10-06 2:06 PM, Charles Marcus wrote: Yes there is... use the MSI system, which will take care of things like unpacking to the environments /tmp directory, launching the installer after unpacking (like it does now), then - and here is the trickey part I guess - detect a current installation, and offer to upgrade it, or to install a parallel version. Oh - and one thing that I'd really like to see is a simple 'incremental updater' that just downloads a 'patch' file and patches itself, like Firefox and Thunderbird and lots of other programs do now. +10 --Jean +1 Michele -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
El 06/10/10 18:21, Scott Furry escribió: Windows becomes the corner case... There is no defined standard of where to install files, just suggestions. And an update mechanism becomes an external program. There are 3rd party apps for updating sources. I believe we should explore those options. Great think and great summary, Scott! -- ~~~ Prof. Román H. Gelbort http://www.piensalibre.com.ar 10 años usando OpenOffice.org, libre, gratuito y seguro ~~~ -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
On 10/06/2010 11:39 AM, Marc Paré wrote: Le 2010-10-06 14:30, Steven Shelton a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/6/2010 2:21 PM, Charles Marcus wrote: Oh - and one thing that I'd really like to see is a simple 'incremental updater' that just downloads a 'patch' file and patches itself, like Firefox and Thunderbird and lots of other programs do now I would vote for this too. It would be amazing if it were capable. This functionality is already available in package managers, if we just take care to use it. yum, for example, supports delta RPMs. The way this works is LibO would publish delta RPMs that contain all the differences from the previous release, and then the users yum package manager would download the delta RPM, build the full RPM from it, and install. This approach has been in use for about a year and a half by fedora. I'm not sure about apt-get systems -- they probably have something similar. It really saves on bandwidth. Jon -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
Le 2010-10-06 14:59, Per Eriksson a écrit : Hi, Marc Paré skrev 2010-10-06 20:39: Le 2010-10-06 14:30, Steven Shelton a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/6/2010 2:21 PM, Charles Marcus wrote: Oh - and one thing that I'd really like to see is a simple 'incremental updater' that just downloads a 'patch' file and patches itself, like Firefox and Thunderbird and lots of other programs do now I would vote for this too. It would be amazing if it were capable. Marc +1 Tell me how I can help. Best Per If there were a common method to do incremental updates (linux) to avoid too much work from the devs, this would be great. Judging by the discussions, it looks like it could be a challenge though. Marc -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
On Wed, Oct 6, 2010 at 7:21 PM, Scott Furry scott.wl.fu...@gmail.com wrot e: On 06/10/10 05:00 PM, Jon Hamkins wrote: On 10/06/2010 11:39 AM, Marc Paré wrote: Le 2010-10-06 14:30, Steven Shelton a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/6/2010 2:21 PM, Charles Marcus wrote: Oh - and one thing that I'd really like to see is a simple 'increment al updater' that just downloads a 'patch' file and patches itself, like Firefox and Thunderbird and lots of other programs do now I would vote for this too. It would be amazing if it were capable. This functionality is already available in package managers, if we just take care to use it. yum, for example, supports delta RPMs. The wa y this works is LibO would publish delta RPMs that contain all the differences from the previous release, and then the users yum package manager would download the delta RPM, build the full RPM from it, and install. This approach has been in use for about a year and a half by fedora. I'm not sure about apt-get systems -- they probably have something similar. It really saves on bandwidth. Jon And I agree with Jon. +1 I've run into situations with OOo where installing/updating an extension becomes a mess. End result is having to clean out configurations/cache and start from scratch. Not Fun :( Not Recommended :P IIRC, apt-get uses a .diff file mechanism to apply patches. What I would very much like to avoid is the situation of a repository ful l of 'abandonware'. Having vast amounts of choice for extensions is wonderful for the communi ty, so long as these extensions are being actively maintained. This I think i s the problem faced by many community projects where users contribute the extension, based on some version of the main program. As the main program evolves, the extension suffers 'code rot' and joins a storage device full of unmaintained/abandoned extensions based on a particular version of the ma in program. (e.g. Apple - app store, Mozilla - add-on, Netbeans, etc.) Package Management, through dependencies, would ensure that an unsuitable extension is not used or installed. The end user can rely on this system to help keep their install stable and secure. Just tweaking a file in a pack age (like being able to edit a Mozilla add-on install.rdf file to pass a basi c revision check) can't be accomplished. The extension contributor needs to update the extension, or someone else can pickup maintaining the extensio n. To me its a bit of waste where every large development entity has its own software repository based on their own update mechanisms. Someone else ha s figured out the hard parts, lets leverage their work rather than reinvent . Let's strive to let the users work on the operating system they've chosen and work in a way that is consistent with that OS. @Roman TY. Just trying to keep the conversation lively and informed. :D Cheers, Scott Furry We already have the opendesktop.org websites like kde-look.org, gnome-apps.org, and InkscapeStuff.org. These sites allow for users uploading and downloading files, support nested categorization, and have pretty powerful searching. The sites also implement the Get Hot New Stuff freedesktop.org API, which is specifically designed for locating, downloading, and updating content. Rather than re-inventing the wheel, it may be good to at least check whether the websites can be used for hosting the content and Get Hot New Stuff used for downloading and updating it. -Todd -- To unsubscribe, send an empty 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/
[tdf-discuss] Automatic Updates
Not sure where thinking is on this for LiBO at the moment, but is it concievable that updating even to each new version could, after a User response, be automatic and if elected by the User - replace the previous version automatically please? Paul -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
У сре, 06. 10 2010. у 13:22 +1300, Paul A Norman пише: Not sure where thinking is on this for LiBO at the moment, but is it concievable that updating even to each new version could, after a User response, be automatic and if elected by the User - replace the previous version automatically please? Paul Hi Paul, A first step would be to replicate the update notification feature available in the OpenOffice.org. I guess only infrastructure is missing for that one. I remember last year in Orvieto there were some talks about new packaging for all platforms that would allow online installation (allowing user to select, download and install any combination of languages, cutting space requirements to do full install sets). I do not know what is the current status of this development and if it would be easier to add autoupdate feature after that task is completed. Kind regards, Goran Rakic -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
What I have found is that under OOO I have always been left with install directories with Mbs of space used for previous installations, the uninstall or new install doesn't seem to have removed them. I have been thinking tha it would be neat to have as it were, one install of LiBO and have it updated in all the same directories all the time, even if it were a new version of LiBO that was being installed - updated, unless the User specifically elected to have multiple installations of different versions, making the default that there is only ever one main copy that is updated all the time. Paul On 6 October 2010 13:35, Goran Rakic gra...@devbase.net wrote: У сре, 06. 10 2010. у 13:22 +1300, Paul A Norman пише: Not sure where thinking is on this for LiBO at the moment, but is it concievable that updating even to each new version could, after a User response, be automatic and if elected by the User - replace the previous version automatically please? Paul Hi Paul, A first step would be to replicate the update notification feature available in the OpenOffice.org. I guess only infrastructure is missing for that one. I remember last year in Orvieto there were some talks about new packaging for all platforms that would allow online installation (allowing user to select, download and install any combination of languages, cutting space requirements to do full install sets). I do not know what is the current status of this development and if it would be easier to add autoupdate feature after that task is completed. Kind regards, Goran Rakic -- To unsubscribe, send an empty e-mail to discuss+unsubscr...@documentfound ation.org All messages you send to this list will be publicly archived and cannot b e deleted. List archives are available at http://www.documentfoundation.org/lists/di scuss/ -- To unsubscribe, send an empty 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/
Re: [tdf-discuss] Automatic Updates
On 05/10/10 07:36 PM, Paul A Norman wrote: What I have found is that under OOO I have always been left with install directories with Mbs of space used for previous installations, the uninstall or new install doesn't seem to have removed them. I have been thinking tha it would be neat to have as it were, one install of LiBO and have it updated in all the same directories all the time, even if it were a new version of LiBO that was being installed - updated, unless the User specifically elected to have multiple installations of different versions, making the default that there is only ever one main copy that is updated all the time. Paul On 6 October 2010 13:35, Goran Rakicgra...@devbase.net wrote: У сре, 06. 10 2010. у 13:22 +1300, Paul A Norman пише: Not sure where thinking is on this for LiBO at the moment, but is it concievable that updating even to each new version could, after a User response, be automatic and if elected by the User - replace the previous version automatically please? Paul Hi Paul, A first step would be to replicate the update notification feature available in the OpenOffice.org. I guess only infrastructure is missing for that one. I remember last year in Orvieto there were some talks about new packaging for all platforms that would allow online installation (allowing user to select, download and install any combination of languages, cutting space requirements to do full install sets). I do not know what is the current status of this development and if it would be easier to add autoupdate feature after that task is completed. Kind regards, Goran Rakic -- To unsubscribe, send an empty 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/ Paul, I do agree with the principles of your suggestion. Certainly on Windows installs this is true as evidenced by the Install Folder left on the desktop. And leaving the install folders around, not cleaning up after the install, or an uninstall not removing everything that was installed seems rather unprofessional. So, yes, I concur. However, I believe that may be only for Windows... *nix(Linux|Unix) installs can use a variety of install/package management programs (e.g. apt, yum, rpm, et al.) that resolve this issue. And these package management programs can also purge configuration files when removing a package. Package management also handle the kind of automatic update functionality you mention. But this is for *nix only... Any installation method that is deployed, in my mind, must 'respect' the package management of the base operating system. I get rather annoyed with multiple types of update/install mechanisms (setup.py for certain python based apps for example) that seem to circumvent OS package management programs. But there is no 'one size fits all' solution. There are numerous install frameworks (e.g. NSIS - NullSoft Install Script[Win only], or IzPack[Java - used by scala]). Again, they seem to circumvent package management on *nix machines while catering to Windows based installs. Problem is that Windows doesn't have a package management system. There is no one simple way to install, update or uninstall. Yes, there is msiexec, but that just provides a means to an end and doesn't handle update mechanisms nor framework/standardize installs. As for update mechanisms, we're left with 3rd party programs. Other than making sure that LibO cleans up after itself, how much effort do we want to put into installers? Regards, Scott Furry -- To unsubscribe, send an empty 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/
