Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)

On Fri, Oct 8, 2010 at 5:46 PM, Marc Paré <marc@marcpare.com> wrote:
> Le 2010-10-08 17:22, todd rme a écrit :
> > On Fri, Oct 8, 2010 at 4:53 PM, Marc Paré<marc@marcpare.com>  wrote:
> > > Le 2010-10-08 16:47, RGB ES a écrit :
> > > > 2010/10/8 Scott Furry<scott.wl.furry@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+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/