Automatic Updates

classic Classic list List threaded Threaded
67 messages Options
Next » 1234 « Prev
Charles Marcus Charles Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Unsubscribe link broken

On 2010-10-07 5:06 PM, Goran Rakic wrote:
> As this can confuse other people, and we should try to make unsubscribe
> for people as easy as possible to avoid angry emails, can we just drop
> some words to make it fit in a single line:

Mine *are* on a single line... ?

--

Best regards,

Charles
--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Scott Furry Scott Furry
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Charles Marcus
  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 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.

>>  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.
>
Again...a package is supplied in a compressed archive format, albeit
with a different extension.
> 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.
http://en.wikipedia.org/wiki/Deb_(file_format)
>> 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...
+1
You and me both.
Know just enough to be dangerous, but not enough to be helpful. :D

Regards,
Scott Furry

--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Charles Marcus Charles Marcus
Reply | Threaded
Open this post in threaded view
|

Re: 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 provided all of
these different packages. How about we make building LibO easier,
provide access to the source, and let the package maintainers take it
from there?

--

Best regards,

Charles
--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Scott Furry Scott Furry
Reply | Threaded
Open this post in threaded view
|

Re: 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 work
(or DF pays someone to do it) LibO will either *never make into the
repositories* -or- *become an extremely low priority* for 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.
>> 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.
>
> Again - let the distro package maintainers do the heavy lifting there...
> all LibO needs to do is provide access to the source.
This is why I suggestion packaging specialists. See my comments about
Debian above.
> Maybe one problem in our communication here is you seem to be focused on
> the historical process of the OOo community has always provided all of
> these different packages. How about we make building LibO easier,
> provide access to the source, and let the package maintainers take it
> from there?
DF already provides access to the source, as well as instructions on how
to build the source, both available from the DF home page. I suspect
that my strict-*nix focus and trying to communicate non-windows may also
be an issue.

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. 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?

Regards,
Scott Furry

--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Eric Hoch Eric Hoch
Reply | Threaded
Open this post in threaded view
|

Re: 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 [hidden email]
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/

Thorsten Behrens Thorsten Behrens
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Per Eriksson
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 [hidden email]
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/

drewjensen drewjensen
Reply | Threaded
Open this post in threaded view
|

Re: 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 [hidden email]
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/

Document Foundation Mail Archives
Eric Hoch Eric Hoch
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by vuhung
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 <[hidden email]> 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 [hidden email]
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/

Sveinn í Felli Sveinn í Felli
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Scott Furry
Totally agree on an diff-update mechanism through
distribution package managers. (See more below)

Þann fös  8.okt 2010 06:37, skrifaði Eric Hoch:

> 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 other
s
>>>> out there in the community. It would be great if they (and their
>>>> skills) could be be brought together allowing for a one-stop-downloa
d

>>>> 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.

Anyway LibO needs to build its own distribution packages;
milestones for testing, langpacks etc. Many translators and
testers do not know how to compile from source. So far OOo
testing packages have been slightly different from the final
'distro-patched' ones (not using native dialogs etc).
I think its never going to be viable to distribute those
testing packages through the distro channels, mostly due to
time constraints.

> 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.

Correct, and in enterprise environment there may also be
additional patches/branding.

Being an OOo/LibO translator, I'd love if such an update
mechanism would take into account the 'normal' workflow in
development of the software. Very simplified progress below:

- devs plot their new exploits ;-)
- devs+translators work towards milestones -> testing*
- devs+translators work towards a release -> testing*
  ---release---
  (everyone dumps their OOo/LibO issued packages for the
distro versions)
- devs work on bugfixes -> security/bugfix upgrades
- translators work on l10n-fixes -> language upgrades**

* would be nice if those testing packages could be upgraded
by diff instead of pulling the whole install, many testers
have bandwidth restrictions.

** post-release language upgrades should be scheduled quite
soon after release (say 3 weeks + 4 months later), there's
always some errors that slip through and user feedback is
always most active just after a release. Such upgrades
should be tiny diffs.

Other things mentioned in this thread have been informative,
I'm not going to comment on the one-user-setup vs
system-wide, your mileage may vary...

Just thoughts,

Sveinn í Felli

--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Robert Sedak Robert Sedak
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Thorsten Behrens
 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 [hidden email]
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/

Friedrich Strohmaier Friedrich Strohmaier
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Thorsten Behrens
Hi Thorsten, *,

+1

nothing more to add..

Thorsten Behrens schrieb:

>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


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 updated on 2010-10-07

--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Charles Marcus Charles Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Scott Furry
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 already on my reading list - which is already large
enough to keep me busy until at least star-date 4392.7... :)

--

Best regards,

Charles
--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Charles Marcus Charles Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Thorsten Behrens
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 [hidden email]
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/

Cor Nouws Cor Nouws
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

Charles Marcus wrote (08-10-10 14:28)

> 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).

+ 1

--
  - giving openoffice.org its foundation :: The Document Foundation -
  - ideas/remarks for the community council? See
    http://wiki.services.openoffice.org/wiki/Community_Council

--
To unsubscribe, send an empty e-mail to [hidden email]
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/

IanW IanW
Reply | Threaded
Open this post in threaded view
|

Re: Unsubscribe NOT working!!!

In reply to this post by Charles Marcus
  Hi All

Whoever is running this list PLEASE sort the Unsubscribe system out!!

When I originally subscribed I got two automatic replies and the mail
started to come in the next day - No problem

However I find there is just too much traffic and decided to
unsubscribe. I sent off two unsubscribe messages as detailed and again
got two automatic replies. That was over a week ago and I have not been
removed from the list!!!

PLEASE sort this out. (and take me off both lists)

Thank you

--

*/_Ian Whitfield_/*//
ZS6CDX
**/
/
--
To unsubscribe, e-mail to [hidden email]
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/

Florian Effenberger Florian Effenberger
Reply | Threaded
Open this post in threaded view
|

Re: Unsubscribe NOT working!!!

Hi Ian,

> PLEASE sort this out. (and take me off both lists)
>

the system works, but I unsubscribed you manually right now from the
discuss list. Which other list shall I unsubscribe you from?

Florian

--
Florian Effenberger <[hidden email]>
Steering Committee and Founding Member of The Document Foundation
Tel: +49 8341 99660880
Fax: +49 8341 99660889
Mobile: +49 151 14424108
Skype: floeff | Twitter/Identi.ca: @floeff


--
To unsubscribe, e-mail to [hidden email]
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/

Charles Marcus Charles Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Unsubscribe NOT working!!!

On 2010-10-08 9:29 AM, Florian Effenberger wrote:
> PLEASE sort this out. (and take me off both lists)

Ian - the email you got was a confirmation that actually requires you to
click the CONFIRMATION link in it - if you don't click  the link, you
won't be unsubscribed.

--

Best regards,

Charles
--
To unsubscribe, e-mail to [hidden email]
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/

usonaulo-pete usonaulo-pete
Reply | Threaded
Open this post in threaded view
|

Re: Unsubscribe NOT working!!!

In reply to this post by Florian Effenberger


--- On Fri, 10/8/10, Florian Effenberger <[hidden email]> wrote:

> From: Florian Effenberger <[hidden email]>
> Subject: Re: [tdf-discuss] Unsubscribe NOT working!!!
> To: [hidden email]
> Cc: "Ian Whitfield" <[hidden email]>
> Date: Friday, October 8, 2010, 9:29 AM
> Hi Ian,
>
> > PLEASE sort this out. (and take me off both lists)
> >
>
> the system works, but I unsubscribed you manually right now
> from the
> discuss list. Which other list shall I unsubscribe you
> from?
>
> Florian
>
> --
> Florian Effenberger <[hidden email]>
> Steering Committee and Founding Member of The Document
> Foundation
> Tel: +49 8341 99660880
> Fax: +49 8341 99660889
> Mobile: +49 151 14424108
> Skype: floeff | Twitter/Identi.ca: @floeff
>
>
> --
> To unsubscribe, e-mail to [hidden email]
> 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/
>
>
--
To unsubscribe, e-mail to [hidden email]
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/

Thorsten Behrens Thorsten Behrens
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Charles Marcus
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 [hidden email]
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/

Charles Marcus Charles Marcus
Reply | Threaded
Open this post in threaded view
|

Re: 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 [hidden email]
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/

Next » 1234 « Prev