Re: [tdf-discuss] Automatic Updates

On Wed, Oct 6, 2010 at 7:21 PM, Scott Furry <scott.wl.furry@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+unsubscribe@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/