To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=46226


User cloph changed the following:

                  What    |Old value                 |New value
================================================================================
                  Keywords|                          |oooqa
--------------------------------------------------------------------------------




------- Additional comments from [EMAIL PROTECTED] Sat Apr  2 03:17:18 -0800 
2005 -------
I don't like any of the proposed "fixes".

1) as you already mentioned disables other things and although not needed by the
spec, you should specify this in your rpm-configuration, not in the spec.

But people usually are not interested in fixing their build-system, I'd prefer
either this solution because it doesn't introduce any further hacks (you don't
have to take care of the link-policies anyway (who will install the
freedesktop-package if there is a suse-one) and no other post-install-scripts
are useful for this spec)

or a simple "export NO_BRP_STALE_LINK_ERROR=yes"

2) Is approach is plain wrong IMHO.

This is introducing error-prone hacks to workaround a "fix" caused by another
"error"

The problem is: relative links that cross page boundries.
So you should fix this. Nothing more, nothing less.
# Task: go through the files in $RPM_BUILD_ROOT and 
# relink symbolic links so that:
# links crossing top level directory boundaries (/usr/* -> /etc/*)
#   are absolute links [...]"

The only links included are the desktop-links in /usr/share/applications to
../../etc/....
-> relative ones.

Furthermore:
"-checks for the existence of the link target (helps to find typos)"

This is impossible. How can the build-host know what targets are available on
the installing-system? If the script really attempted this, it would be
broken/only suitable for building packages for one single host -> not suitable
for building cross-distro-packages like the freedesktop one.
Some inner voice is telling me that it is better not to "fix" this problem since
the real problem is the script that is suitable for building a whole distro is
used in an installation used to build distribution-independent-packages

The targets are provided by the individual modules. So specifying them in the
spec is an error/hack.

But as stated before: People don't want to think about their build-system,
having them fix it is too much of a burden, so introduce workarounds...

%define _unpackaged_files_terminate_build 0 

-> This should be placed in the rpm-configuration/given as argument, but not in
the spec. Unless you can give a good reason why you want to hide errors in the
spec-file, this won't be added.

>In fact, I don't like the current solution when the RPMs are created at this
>stage. It would be better to create them when the RPMs for the application
>are created. It would help to avoid the ugly symlink in /etc/ if all the RPMs
>are created at once.

The "stage" when the rpms are created has nothing to do with the symlink in /etc
or this problem. The other menu-packages simply don't use an install stage at
all, but use dirty makefile-magic (so defining __os_install_post to %{nil} would
be closest to the other ones} - so the script is not run. But again: this has
nothing to do with a link in /etc

This solution solves the following:
* allow for relocatable packages
* allow for desktop-integration
* allow for individual packages (writer, calc, math, ...)

If you know another way to accomplish all three items without a link in a fixed
location, please file another issue and cc me.

---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to