Hi Marco,
M. Fioretti wrote:
On Fri, May 13, 2005 10:21:31 AM +0200, Jürgen Schmidt
([EMAIL PROTECTED]) wrote:
But of course deploying templates with UNO packages would be an
interesting idea as well.
You can see from this remark that UNO packages were not made to install
templates or
Hi,
Directory standardisation is one thing linux distributions do right.
I doubt it. I think that Mathias is knows what he's talking about, and
he's referring to a third party (e.g. me) writing an RPM for an OOo
add-on. And I think Nicolas interpreted this correctly, and responded
with a
On Mar 17 mai 2005 14:44, Joerg Barfurth a écrit :
Hmmm... not so interesting for stuff that could be used outside OO.o,
is it?
Not interesting for stuff that could be used without UNO. But why should
a *UNO* package manager even try to do that? OTOH I wouldn't expect all
native package
On Mar 17 mai 2005 14:57, Joerg Barfurth a écrit :
Hi,
Well, fd.o would probably make that $XDG_DATA_DIRS/templates/filetype/
or so, which means that an entire search path needs to be derived from
an environment variable, which is more complicated to inject into the
OOo-internal system...
M. Fioretti wrote:
On Sat, May 14, 2005 01:30:19 AM +0200, Mathias Bauer
([EMAIL PROTECTED]) wrote:
Yes, Daniel names it: we want to see UNO package based deployment
replacing the document based one. Together with our basic common
agreement that we want to start investigating how to create
M. Fioretti wrote:
Daniel,
2) note that I and Nicolas are not even asking that you or others give
up UNO packaging. We are saying please find out and consistently do
whatever is necessary so that it is _also_ easy for _others_ to
ah, you mean we should think about your problem (ok not only
On Fri, May 13, 2005 09:12:07 AM +0200, Jürgen Schmidt
([EMAIL PROTECTED]) wrote:
M. Fioretti wrote:
Daniel,
2) note that I and Nicolas are not even asking that you or others give
up UNO packaging. We are saying please find out and consistently do
whatever is necessary so that it is
M. Fioretti wrote:
On Fri, May 13, 2005 09:12:07 AM +0200, Jürgen Schmidt
([EMAIL PROTECTED]) wrote:
First idea:
1. simply put thre UNO pakcage in a rpm
2. find a common directory where the UNO package will be installed from
the rpm
3. post install script to run unopkg on the package for
Nicolas Mailhot wrote:
Are you kidding ?
Of course it was a joke. Do you know smilies?
But as in many jokes there is grain of truth in it, so also in this one
(at least IMHO).
Directory standardisation is one thing linux distributions do right.
The first question of a packager comming from
M. Fioretti wrote:
I already thought that in this thread you and others have talked and
worried too much on the fragmentation of Linux platforms. Nobody asked
SUN to solve that.
Oh, if we only talked about things that not have been touched already,
this list would become very quiet. :-)
On Fri, May 13, 2005 10:21:31 AM +0200, Jürgen Schmidt
([EMAIL PROTECTED]) wrote:
But of course deploying templates with UNO packages would be an
interesting idea as well.
BTW, what are the dependencies of unopkg? Does it by any mean
pretend that all of OpenOffice is installed?
yes,
M. Fioretti wrote:
I think that UNO packages convey a more professional system
Daniel,
1) what do you mean exactly with the statement above?
Uhmm... exactly what I said. Distributing addons inside documents looks
amateurish IMHO.
2) note that I and Nicolas are not even asking that you or others
M. Fioretti wrote:
It is easier to create a constitution for the European Union than
it is to get the Linux distributors to create a common platform. :-)
Are you kidding ?
Directory standardisation is one thing linux distributions do right.
He is probably only confusing, as I noted in my reply,
Daniel Carrera wrote:
M. Fioretti wrote:
2) note that I and Nicolas are not even asking that you or others give
up UNO packaging. We are saying please find out and consistently do
whatever is necessary so that it is _also_ easy for _others_ to
(automatically) make a native Linux
On Sat, May 14, 2005 01:30:19 AM +0200, Mathias Bauer
([EMAIL PROTECTED]) wrote:
Yes, Daniel names it: we want to see UNO package based deployment
replacing the document based one. Together with our basic common
agreement that we want to start investigating how to create native
packages from
Hi,
M. Fioretti wrote:
Nobody should use sxw files for deployment. We use *UNO packages*.
Sorry for not getting back on this earlier. Thanks for the detailed
explanation, but I still have some doubts:
1) Are these UNO packages useable/recommended also for single macros,
templates, clip-art?
Hi,
M. Fioretti wrote:
Does it explain how to create stuff that doesn't create problems to
Linux distributors (in the sense explained at the beginning of this
thread)? That is, how to provide stuff that can be directly used by
others to create native Linux packages in whatever format?
I think
On Thu, May 12, 2005 12:37:53 PM +0200, Joerg Barfurth
([EMAIL PROTECTED]) wrote:
More exactly, the pain is if add-ons are _only_ distributed as OO.o
native packages: and if Linux users are not recommended to prefer,
whenever available, the native packages for their distribution.
Why
M. Fioretti wrote:
1) Are these UNO packages useable/recommended also for single macros,
templates, clip-art? That is, not core, serious stuff, made by
professionals?
UNO packages are recommended for deployment of macros, yes. Basically
they could be used for templates and clip-arts
M. Fioretti wrote:
There is another side of the issue, at least for templates and
clip-art. This kind of stuff should be installed in such a way to be
automatically visible to all word processors. Especially now that
KOffice is converging on OpenDocument, why should I install an
OpenDocument
Mathias Bauer wrote:
3) Where is the official documentation/web page explaining all this
to new, potential, one-time contributors? And *deprecating* the use
of .sxw or .sxc files as installers?
That's a delicate story. :-)
We tried to advertise our UNO packages several times, but many people
On Thu, May 12, 2005 23:51:09 PM +0200, Mathias Bauer
([EMAIL PROTECTED]) wrote:
M. Fioretti wrote:
There is another side of the issue, at least for templates and
clip-art. This kind of stuff should be installed in such a way to be
automatically visible to all word processors.
[...]
On Jeu 12 mai 2005 23:51, Mathias Bauer a écrit :
M. Fioretti wrote:
There is another side of the issue, at least for templates and
clip-art. This kind of stuff should be installed in such a way to be
automatically visible to all word processors. Especially now that
KOffice is converging on
On Fri, May 13, 2005 07:44:39 AM +0200, Nicolas Mailhot
([EMAIL PROTECTED]) wrote:
On Jeu 12 mai 2005 23:51, Mathias Bauer a écrit :
It is easier to create a constitution for the European Union than
it is to get the Linux distributors to create a common platform. :-)
Are you kidding ?
On Wed, Apr 27, 2005 16:08:07 PM +0200, Mathias Bauer
([EMAIL PROTECTED]) wrote:
M. Fioretti wrote:
Nobody (not me anyway) asked to use _one_ form of package. What is
important is make sure that everything is always made available
online in source form, that the distributors can pick and
Hi Marco,
M. Fioretti wrote:
[...]
Sorry for not getting back on this earlier. Thanks for the detailed
explanation, but I still have some doubts:
1) Are these UNO packages useable/recommended also for single macros,
templates, clip-art? That is, not core, serious stuff, made by
On Wed, May 11, 2005 17:56:56 PM +0200, io ([EMAIL PROTECTED]) wrote:
Nobody should use sxw files for deployment. We use *UNO packages*.
Sorry for not getting back on this earlier. Thanks for the detailed
explanation, but I still have some doubts:
1) Are these UNO packages
Hi all,
Nicolas Mailhot wrote:
Great. In that case the only thing we need to do rpm packaging is a way to
specify an installation prefix (basically you tell your utility to install
for the local OO.o installation, prepending a specific root. rpm then
compresses the contents of this root,
On Sun, Apr 24, 2005 22:02:08 PM +0200, Mathias Bauer
([EMAIL PROTECTED]) wrote:
M. Fioretti wrote:
So you must not click something in ooo that opens an ooo specific
program that messes up the system. You must make sure that the
_native_ installer can present, in its package selection
On Tue, Apr 26, 2005 14:15:34 PM +0200, Nicolas Mailhot
([EMAIL PROTECTED]) wrote:
Do you remember the complaints that OOo only offers RPMs?
You really don't imagine the level of complaints not providing native
packages will raise.
And by not providing native packages I don't
Hi,
Nobody (not me anyway) asked to use _one_ form of package. What is
important is make sure that everything is always made available online
in source form, that the distributors can pick and package their way
for automatic installation and upgrade. *Without* extra work like
dissecting a
Shoshannah Forbes wrote:
On 26/04/2005, at 09:22, Mathias Bauer wrote:
I have an Add-On component installed in my OOo user profile for several
years now. I installed a lot of new versions (forwards and backwards in
version history) since then and it still works like a charm.
You are
On Mer 27 avril 2005 9:02, Laurent Godard a écrit :
needs
And as it has already been said (mathias ?) if it is a corporate policy
not to install extra addons, let admins do their job and remove the menu
entry. The massive deployement of UNO packages is not an issue.
Corporate policy is
On Mar 26 avril 2005 15:44, Mathias Bauer a écrit :
Nicolas Mailhot wrote:
And by not providing native packages I don't necessarily mean not
providing native packages at the OO.o level but not creating an
environment where other people can easily provide them.
Fine, why didn't you mention
On Wed, 2005-04-27 at 08:39 +0200, M. Fioretti wrote:
Or, in the same multiuser/automatic maintenance scenario deal with
anything that adds, say, stuff requiring Java, fonts or dictionaries
conflicting with those in other apps, etc...
This is a good point.
There are lots of good ideas
M. Fioretti wrote:
Nobody (not me anyway) asked to use _one_ form of package. What is
important is make sure that everything is always made available online
in source form, that the distributors can pick and package their way
for automatic installation and upgrade. *Without* extra work like
On Mer 27 avril 2005 16:08, Mathias Bauer a écrit :
M. Fioretti wrote:
Nobody (not me anyway) asked to use _one_ form of package. What is
important is make sure that everything is always made available online
in source form, that the distributors can pick and package their way
for automatic
Nicolas Mailhot wrote:
And when I write developpers here I mean the people that provide software
to end-users. I does not mean native packaging should be taken care of by
the people who write the extensions, just that this service must be taken
care of by someone in the software-producing chain,
Le mercredi 27 avril 2005 15:06 -0400, Daniel Carrera a crit :
Nicolas Mailhot wrote:
And when I write developpers here I mean the people that provide software
to end-users. I does not mean native packaging should be taken care of by
the people who write the extensions, just that this
M. Fioretti wrote:
But how do you install OO.o stuff automatically for multiple users? Or
update automatically when a new version of some macro and/or the OS?
Or, in the same multiuser/automatic maintenance scenario deal with
anything that adds, say, stuff requiring Java, fonts or
Shoshannah Forbes wrote:
On 25/04/2005, at 15:01, Mathias Bauer wrote:
Do you really want that
*everything* on your system must be installed through the same
installer/packager? Every script, every macro, every configuration
file?
If yes: then I understand your goal; but I doubt that this
Shoshannah Forbes wrote:
On 25/04/2005, at 01:04, Mathias Bauer wrote:
I would like to see a concrete use case described where an Add-On
installation creates a problem. Maybe that could help me to understand
where you're aiming at.
Simple one- installation for multiple users on the
On Mar 26 avril 2005 9:15, Mathias Bauer a écrit :
IMHO your standpoint it too strict. You see the single software database
as a value per se, I only see it as a means to and end (I see everything
this way BTW ;-))
Right now none of the people who worked both with separate and integrated
On Mon, 2005-04-25 at 19:52 +0200, Nicolas Mailhot wrote:
Mathias Bauer wrote :
| This might seems mightily restrictive (and it is) but the end result
is
| when one file on the system has a problem you know what package owns it
| and fixing this package is sufficient to heal the system. This
Nicolas Mailhot wrote:
Right now none of the people who worked both with separate and integrated
solution agreed with you this standpoint is too strict. I know it's not
what you want to hear but it's what the users demand.
I agree that your standpoint is too strict. I see a lot of value in
OOo's
Ken Foskey wrote:
I like the cpan model and think we should base it around that.
I love CPAN, it rocks.
:-)
Cheers,
Daniel.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 26/04/2005, at 09:22, Mathias Bauer wrote:
I have an Add-On component installed in my OOo user profile for several
years now. I installed a lot of new versions (forwards and backwards in
version history) since then and it still works like a charm.
You are talking about a *single user* scenario
Le dimanche 24 avril 2005 23:54 +0200, Mathias Bauer a crit :
Nicolas Mailhot wrote:
Let's just say that linux users and sysadmins strongly disagree with you
for their own reasons, that they yelled at every single software system
that tried to do this very thing, and that none of the
Le dimanche 24 avril 2005 23:59 +0200, Mathias Bauer a crit :
I don't know if it is system-update proof, because I don't know what
that means. If you could describe it maybe we can find out if this
applies to the OOo Add-On installer.
It means in 2-3 years I can take a Linux system, issue
On Lun 25 avril 2005 0:04, Mathias Bauer a écrit :
M. Fioretti wrote:
2) the system package manager (rpm, apt, whatever) is not informed
of what is added, hence it might not object later if you install
with it some 3rd party thing that messes up what you added by
hand to OO.o,
Nicolas Mailhot wrote:
Someone asked the other day why the Ximian fork even existed (and was
widely used). This is one big reason. People somehow refuse to accept
distribution advice when it goes against common windows wisdom, so
distributions have to do their own thing (even Ximian competitors
On Lun 25 avril 2005 11:24, Daniel Carrera a écrit :
Nicolas Mailhot wrote:
Someone asked the other day why the Ximian fork even existed (and was
widely used). This is one big reason. People somehow refuse to accept
distribution advice when it goes against common windows wisdom, so
Nicolas Mailhot wrote:
Someone asked the other day why the Ximian fork even existed (and was
widely used). This is one big reason. People somehow refuse to accept
distribution advice when it goes against common windows wisdom, so
distributions have to do their own thing (even Ximian competitors
Nicolas Mailhot wrote:
Le dimanche 24 avril 2005 à 23:54 +0200, Mathias Bauer a écrit :
Nicolas Mailhot wrote:
Let's just say that linux users and sysadmins strongly disagree with you
for their own reasons, that they yelled at every single software system
that tried to do this very
Nicolas Mailhot wrote:
On Lun 25 avril 2005 0:04, Mathias Bauer a écrit :
M. Fioretti wrote:
2) the system package manager (rpm, apt, whatever) is not informed
of what is added, hence it might not object later if you install
with it some 3rd party thing that messes up what you added by
On Lun 25 avril 2005 12:37, Mathias Bauer a écrit :
Nicolas Mailhot wrote:
BTW: do you know the OOo Add-On installer at all and the way it works?
Don't know and don't care.
OK. You complain about something you don't know. You don't listen to
arguments from others. You think you know
Nicu Buculei wrote:
Mathias Bauer wrote:
On Lun 25 avril 2005 0:04, Mathias Bauer a écrit :
Wether the system package manager needs to be informed depends on the
way the Add-On interacts with the system. If all Add-Ons are self
contained and do not need any other packages except the OOo
On Lun 25 avril 2005 14:01, Mathias Bauer a écrit :
Nicu Buculei wrote:
Mathias Bauer wrote:
On Lun 25 avril 2005 0:04, Mathias Bauer a écrit :
Wether the system package manager needs to be informed depends on the
way the Add-On interacts with the system. If all Add-Ons are self
contained and
Hi,
Nicolas Mailhot wrote:
Le dimanche 24 avril 2005 23:54 +0200, Mathias Bauer a crit :
Let's just say that linux users and sysadmins strongly disagree with you
for their own reasons, that they yelled at every single software system
that tried to do this very thing, and that none of the
On Lun 25 avril 2005 14:16, Nicolas Mailhot a écrit :
BTW had another poster not an old message of mine I wouldn't have
intervened on this problem at all.
And I might add this message still applies as-is
https://www.redhat.com/archives/fedora-devel-list/2005-March/msg00629.html
--
Nicolas
Nicolas Mailhot wrote:
On Lun 25 avril 2005 12:37, Mathias Bauer a écrit :
OK. You complain about something you don't know. You don't listen to
arguments from others. You think you know everything better and so you
don't need to learn and understand.
And you want me to take you serious?
On 25/04/2005, at 01:04, Mathias Bauer wrote:
I would like to see a concrete use case described where an Add-On
installation creates a problem. Maybe that could help me to understand
where you're aiming at.
Simple one- installation for multiple users on the system, and then
upgrading OOo via the
On 25/04/2005, at 15:01, Mathias Bauer wrote:
Do you really want that
*everything* on your system must be installed through the same
installer/packager? Every script, every macro, every configuration
file?
If yes: then I understand your goal; but I doubt that this is what
people want and what
Le dimanche 24 avril 2005 22:02 +0200, Mathias Bauer a crit :
M. Fioretti wrote:
So you must not click something in ooo that opens an ooo specific
program that messes up the system. You must make sure that the
_native_ installer can present, in its package selection window, its
own
Nicolas Mailhot wrote:
Le jeudi 21 avril 2005 à 13:31 -0400, Daniel Carrera a écrit :
Marco Fioretti wrote:
and it also mentions the firefox installer as another PITA.
In which way is the FF installer a PITA?
It requires heavy human baby-sitting to do the right thing (functionally
and
Daniel Carrer wrote:
A lot of features can be implemented through extensions. If we
made it easier for people to submit and install extensions, we
might get a good sub community there. It could take some pressure
off from the core project.
and also:
What are the chances of a near-future
Marco Fioretti wrote:
snip
When reading about a template and extension installer, their
reaction was:
Please don't...On a package-based system any stuff
not installed via the native packaging system is a cause of much
annoyance and grief...[better]fix something else in openoffice.org
instead of
Marco Fioretti wrote:
and it also mentions the firefox installer as another PITA.
In which way is the FF installer a PITA?
Cheers,
Daniel.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Le vendredi 22 avril 2005 03:04 +1000, Justin Clift a crit :
Marco Fioretti wrote:
snip
When reading about a template and extension installer, their
reaction was:
Please don't...On a package-based system any stuff
not installed via the native packaging system is a cause of much
Le jeudi 21 avril 2005 18:22 +0200, Marco Fioretti a crit :
Daniel Carrer wrote:
What are the chances of a near-future OOo version having an
extension installer, like Thunderbird?
Before getting too excited about this, and starting it, please
consider also the impact on Gnu/Linux
Le jeudi 21 avril 2005 13:31 -0400, Daniel Carrera a crit :
Marco Fioretti wrote:
and it also mentions the firefox installer as another PITA.
In which way is the FF installer a PITA?
It requires heavy human baby-sitting to do the right thing (functionally
and security-wise), is not
On Fri, Apr 22, 2005 03:04:46 AM +1000, Justin Clift
([EMAIL PROTECTED]) wrote:
Marco Fioretti wrote:
snip
When reading about a template and extension installer, their
reaction was:
Please don't...On a package-based system any stuff not installed
via the native packaging system is a cause
72 matches
Mail list logo
