Created attachment 32269 [details]
Slackware menus package

ssa->obr: for you ?

I don't think we will accept a static tar.gz file for inclusion in the
installation set. This would be too likely to break moving to the next releases.

What we would accept is a patch to the "source" tree that generates this tar.gz
during the build (as done for every other desktop-integration package in project
sysui).

@cloph, ihi: I am quite busy atm. Could one of you guys please lend superandrzej
a helping hand. Thanks.

besides the point obr raised (no acceptance of a static package for
menu-integration), there are other issues that should be clarified first.

1) Copyright (did you sign JCA?) - There is not much code in the attached
package, but the logic to create the package probably will be more than ten lines...

2) Actual integration
The only install-script in the package is a script "doinst.sh" but that doesn't
run anything like update-desktop-database or update-mime-database and similar stuff.
So how will the package work with recent versions of gnome/kde that use the
freedesktop.org specs and expect a cache of the entries to be present?

Similar, the icons are only installed to the kde-dirs. So is gnome or other
desktop-environments not supported under slackware?

3) Removal
How does removal of the package work? The doinst-script creates symlinks to
soffice in the /opt/ directory where OOo is expected. How are these links removed?

4) Relocation of "Core"-OOo
With the assumption taken in the doinst-script (OOo installed to
/opt/openoffice.org2.0) the slackware-package breaks relocation of the packages.

cloph,

Here come the answers to your questions.

Ad 1) I didn’t sign JCA. What I have done was mainly reordering openoffice.org
suse menus. Except for changes in paths of two bash scripts, change of symbolic
links, deletion of unnecessary files and adjustments for slackware
requirements(ownership of files, extra description files ) nothing really was
done by me (and for sure nothing that can be called coding).
Here are the steps of package preparation:
1- unpack OO.o package
2- convert openoffice.org-suse-menus-2.0.0-3.noarch.rpm package in to *.tgz
using rpm2tgz utility.
3- install *.tgz package in a “working directory†
4- remove gnome related files
5- move KDE related files to /opt/kde
6- change openoffice.org-2.0-*.desktop symbolic links from
usr/share/applications so that they indicate to the right directory:
/opt/openoffice.org2.0/share/xdg/
7- change in usr/bin openoffice.org-2.0-printeradmin, openoffice.org-2.0 bash
scripts so that they indicate right directory /opt/openoffice.org2.0/program
8- change soffice symbolic link in usr/bin so that it indicate to the right
directory: /opt/openoffice.org2.0/program/
9- copy in to /usr/doc/openoffice.org-2.0.0 LICENSE_en-US, LICENSE_en-US.html,
README_en-US, README_en-US.html (slackware requirement)
10- create in /usr/doc/openoffice.org-2.0.0 README_SLACK with short instructions
how to convert OO.o rpms into slackware .tgz and install them.
11- create short package description in /install/slack-desc
12- change files ownership in to root.root (slackware requirement)
13- create slackware package using makepkg (it is a slackware tool that
basically removes all symbolic links and creates doinst.sh so that that symbolic
links can be restored during installation, then it tar and gzip the content of
“working directoryâ€)


Ad 2) 
For KDE it is enough to have *.desktop files in /opt/kde/share/mimelnk/application
/usr/share/applications

As far as other desktops that implement freedesktop.org specs it should be
enough to copy: openoffice.org.xml into /usr/share/mime/packages/ and have
*.desktop files in /usr/share/applications. Only icons may not be displayed (but
it affects only gnome which is not officially supported in Slackware anymore)
XFCE supports KDE settings

Other DE (blackbox, fluxbox, fvwm, windowmaker)do not have any extra menu
customizations under Slackware and creation of menus is supposed to be done by
users.


Ad 3)
Symlinks can are removed during package removal using either pkgtool(slackware
specific), removepkg (slackware specific) or kpackage (KDE) based on the
information from doinst.sh sctipts that are automatically backuped during
package installation.

Ad 4)
OO.o rpms converted using rpm2tgz locates OO.o in /opt/openoffice.org2.0 that is
why this package refers to this location.

wrt JCA, yes - one can argue about the level of "coding" involved.. Sure the
attached one doesn't include anything worth a JCA or similar, but embedding this
 into the build-system (automating these steps) may result in a makefile with
considerably more "coding".. And preferably this should not be a onetimer, but
as well keeping it up-to-date as development of OOo itself continues.

I as a gnome-user don't like the idea of not supporting gnome.

and wrt steps 6-8) modifying the desktop files, etc. to point "to the right
directory" is arguable as well, the link in /etc/ is meant to keep the packages
relocatable. You have the link in /etc/ point to the right directory.

regarding point 2) it is not enough to only place the files in the directories,
you have to update the cache for the mime and menu files.

Anyway regarding the link-locations I'd prefer that you keep the symlink in
/etc, just like it is done for the other distros. If it is not possible to query
for an install-location for slackware packages, then it at least eases the
maintainer's task when he decides to not place OOo into /opt/openoffice.org2.0 
- he only has to modify one single link instead of every single link.

Anyway- I accept this issue and I'm willing to handle the technical stuff
(integration into build-system, creation of cws, etc.) - But I'm not sure about
relying on the makepkg tool. I don't want to add a dependency to OOo, so if that
stuff can be created without that tool, this should be the way to go.

>wrt JCA, 
How can I do this?

>I as a gnome-user don't like the idea of not supporting gnome.
As I mentioned:  with the package that I sent GNOME is partially supported i.e.
menu entries are visible but icons may not be displayed.


>and wrt steps 6-8) modifying the desktop files, etc. to point "to the right
>directory" is arguable as well, the link in /etc/ is meant to keep the packages
>relocatable. You have the link in /etc/ point to the right directory.

In step 6 and 8 I do NOT modify desktop files themselves. I only modify symbolic
links to them.
In step 7) openoffice.org-2.0-printeradmin, openoffice.org-2.0 in usr/bin are
indeed changed but these files are simple bash scripts and can be recreated
using another simple bash script where a variable defining installation path can
be declared.


>regarding point 2) it is not enough to only place the files in the directories,
>you have to update the cache for the mime and menu files.
Apparently KDE is doing it itself as new entries in KDE menu were visible right
after package installation (no need to updated anything manually or to re-login
into KDE)


>Anyway regarding the link-locations I'd prefer that you keep the symlink in
>/etc, just like it is done for the other distros. If it is not possible to query
>for an install-location for slackware packages, then it at least eases the
>maintainer's task when he decides to not place OOo into /opt/openoffice.org2.0 
>- he only has to modify one single link instead of every single link.

for the steps 6-8 everything can be solved with one bash script where a variable
defining installation path can be declared. So from one release to another,
maintainer would have only to change one and only one variable. ;)


> But I'm not sure about relying on the makepkg tool. I don't want to add a
dependency to
> OOo, so if that stuff can be created without that tool, this should be the way
to go.
Slackware is about simplicity. What makepkg tool is doing is automation of some
manual steps i.e.
- change ownership of files (if desired)
- remove symlinks and create script doinst.sh so that symlinks can be recreated
during installation
- tar and gzip content of working directory.

So makepkg is not necessary.

For the JCA, please sign http://www.openoffice.org/licenses/jca.pdf and mail/fax
it to the adress specified in the form.

> As I mentioned:  with the package that I sent GNOME is partially supported 
> i.e. menu entries are visible but icons may not be displayed.

No - with your package there won't be menu entries in recent versions of gnome
since it doesn't update the desktop-database. And you won't have integration in
the filemanager (mimetypes, what app can handle writer files, etc) - but that's
not critical for me since you wrote that Gnome is not officially supported.

> In step 6 and 8 I do NOT modify desktop files themselves.

Yes. I meant the symlinks. There are no desktop files in the menu-packages, only
links. The desktop-files themselves reside in the individual application-packages.

>>regarding point 2) it is not enough to only place the files in the directories,
>>you have to update the cache for the mime and menu files.
>Apparently KDE is doing it itself as new entries in KDE menu were visible right
>after package installation (no need to updated anything manually or to re-login
>into KDE)

No - it doesn't. You're providing the files in the legacy location/in legacy
format, so KDE doesn't use the freedesktop-ones but the "old" ones, but again
this is not critical.

> for the steps 6-8 everything can be solved with one bash script where a 
> variable defining installation path can be declared. So from one release to 
> another, maintainer would have only to change one and only one variable. ;)

Not sure whether I got this right. You want to include a script in the package
that the admin has to lauch after modifying it? 
Well - I still like the idea of simply changing one single link much better than
to use a script that modifies multiple locations.

> So makepkg is not necessary.

Great.

> Not sure whether I got this right. You want to include a script in the package
> that the admin has to lauch after modifying it? 

No.
I want to use the script during the package creation.
I don't know what is the building environment of OO.o but assuming that there is
bash available I've created a building script where you can control package
creation through few variables.
Tell me if it is of any use.

There are some differences between tar-1.13 and tar-1.15.1 that are causing
differences between tarballs generated by them but I will investigate on it and
let you know.

Created attachment 32786 [details]
package generation bash script

my concern is not changing the link at build time.. That doesn't matter. It is
about not putting a burden on the admins out there that don't want to install
OOo to the default prefix...

Anyway - accepting and starting in cws cloph03

fixed in cloph03

I did not include the doc-stuff (apart from slack-desc) since there is nothing
to document. This package does nothing on its own.
I also kept the link in /etc to make it consistent with the other packages and
to have only one single link that needs to be changed when the user doesn't use
the default prefix for OOo.

Created attachment 35672 [details]
please check whether the file is OK.

I have few remarks:

1)
there is missing directory "./"
without this the package wont remove correctly

2)
usr/bin/openoffice.org-2.0" is not executable
usr/bin/openoffice.org-2.0-printeradmin" is not executable

3)
Having:
usr/doc/openoffice.org_slackware_menus-2.0.2/
with readme's and licenses files are one of slackware package requirements (at
least a license is required to be in line with GPL)
I also think that the content of README_SLACK that I proposed would be useful
for users.


4)
in doinst.sh you are missing:

( cd usr/bin ; rm -rf soffice )
( cd usr/share/applications ; rm -rf openoffice.org-2.0-base.desktop )
( cd usr/share/applications ; rm -rf openoffice.org-2.0-calc.desktop )
( cd usr/share/applications ; rm -rf openoffice.org-2.0-draw.desktop )
( cd usr/share/applications ; rm -rf openoffice.org-2.0-impress.desktop )
( cd usr/share/applications ; rm -rf openoffice.org-2.0-math.desktop )
( cd usr/share/applications ; rm -rf openoffice.org-2.0-printeradmin.desktop )
( cd usr/share/applications ; rm -rf openoffice.org-2.0-writer.desktop )

they are apparently needed in order to remove symlinks when you remove the package

> there is missing directory "./"
> without this the package wont remove correctly

Where is this all documented?

> usr/bin/openoffice.org-2.0" is not executable
> usr/bin/openoffice.org-2.0-printeradmin" is not executable

Thanks. A dumb oversight....

> in doinst.sh you are missing:
>
>( cd usr/bin ; rm -rf soffice )
>[...]
> they are apparently needed in order to remove symlinks when you remove the 
> package

Again: Where can I find information about that. Slackware hides information on
building packages/on what a package must/should contain and how the stuff inside
the package should look like...

Adding this is not a problem, but I'd like to know why...

> Having:
> usr/doc/openoffice.org_slackware_menus-2.0.2/
> with readme's and licenses files are one of slackware package requirements 

Again: Where is this documented?

> (at least a license is required to be in line with GPL)

OOo is not GPL. the license is mentioned in slack-desc. Isn't that enough?

> I also think that the content of README_SLACK that I proposed would be useful
> for users.

It might be OK, but people should read the installation instructions and find
the information there. Documentation-files tend to get outdated very quick. And
having documentation usually requires translation, etc. I don' think it is worth
having that file in the package.

Created attachment 35722 [details]
updated package (doinst.sh, permissions, inlcude ./)

There is one thing that is still wrong:
As I've written last time: "rm -rf" is needed and not "rm -f" otherwise symliks
won't be removed.


Another thing that you mentioned: info on slackware packages.
There is some info on how Slackware package should look like:

http://www.slackbook.org/html/book.html#PACKAGE-MANAGEMENT
http://www.linuxpackages.net/howto.php?page=perfect-package&title=Perfect+Package
http://www.linuxpackages.net/howto.php?page=package&title=Package+Howto

In general there is an assumption that one use typical Slackware tools like:
makepkg, installpkg, removepkg, upgradepkg for slackware package creation and
management. These are bash scripts.
When someone use these tools do not has to bother about ./, symlinks etc.
because it is done by the tool itself.
As you didn't want to have dependence on slackware tools I prepared recipe that
mimic behavior of slackware tools. These thinks are not well documented as it is
not very common to prepare slackware package without slackware tools.
So in a nut shell: It is not that slackware hides information on package
creation. All basic information on how to create package is available but if
someone do not want use slackare scripts then he has to look in to them in order
to figure out how thinks work.

P.S.
I attached scripts so that you can take a look at them.

Created attachment 35732 [details]
slackware scripts

> As I've written last time: "rm -rf" is needed and not "rm -f" otherwise symliks
> won't be removed.

You wrote rm -rf last time, but did not mention that it is necessary.

The links you gave wrt the slackware packages don't help at all. They all claim
"regular tarballs" - which is apparently not true. The do not mention
requirements or other stuff. As you say: People use dedicated tools to build
them - Taking this as reason not to provide information on the
package-requirements or installation process is weired at best.

And I don't want to use these tools since if this was necessary, you certainly
won't get the package for "official" builds - you or someone else with the tools
installed would have to build it - this certainly won't help a lot.

> All basic information on how to create package is available

Where? 

> but if someone do not want use slackare scripts then he has to look
> in to them in order to figure out how thinks work.

Having instructions to run a tool is far different from documenting the format.

I can tell: In MS-Word use File|Save your text in doc format. In your theory
this would be "it is documented how to create doc files".

An even when one has a look at the tool, one never knows *why* it does a certain
thing. (The reason: Because otherwise the tooling might fail may be true for the
technical aspects, but not for the requirements of certain files and the like)

Created attachment 35734 [details]
now with rm -rf

PS: Please don't get my last comment wrong - people often misinterpret my
postings, so I'd better "apologize" beforehand if it was offending :-)

It was a little bit harsh but it was probably because of my unfortunate wording
in previous post.
Comparing transparency of creation of MS Word document to creation of package
using bash script I would call "slightly" exaggerated but apart from this you
are right.
Most of the information I send you I learned through trial and failure method
and "revers engineering" of scripts.

I appreciate that you wanted to spend your time on this issue.
Now I have no more remarks.

committed the changes to cvs → status to fixed.

envisioned release: 2.0.3 → setting target-milestone.

missed the deadline

I was wondering that maybe the name of the package should be
openoffice.org-slackware-menus instead of openoffice.org_slackware_menus as
previously proposed.
This way it's name would be in line with the names of other desktop-integration
packages.
If you agree then the beginnings in slack-desc file should be also changed from
openoffice.org_slackware_menus into openoffice.org-slackware-menus.

Gatekeeper: I do not see any specification and no feature announcement from EIS
for this feature. I have to reject the CWS:SRC680/cloph03 if this task won't
fullfill the requirements described here (see: write 'feature mail(s)'-box:
http://qa.openoffice.org/issue_handling/workflowcharts/taskhandling_workflow_feature_implementation.html

Additional information about how to write specifications can be found here:
http://wiki.services.openoffice.org/wiki/Category:Specification

jsi,

Why do you want specification or feature announcement from EIS for this feature?


This is an integration package. The name is selfexplanatory. It does not have
any impact on core OpenOffice.org. It was made out suse package and adjusted for
slackware needs.

Moreover I looked for similar documentation for suse, redhat and debian. this is
what I've found:
suse, redhat
http://development.openoffice.org/releases/1.9.m49_snapshot.html

debian
http://development.openoffice.org/releases/1.9.m113_snapshot.html
http://development.openoffice.org/releases/1.9.m128_snapshot.html

In the above mentioned links you can find even less information than in case of
this feature request.

regards

Andrzej

Thank you for your answer and your notes: 
A feasture mail does not depend on the impact of the core. It depends on the
impact of the change for developer or user.

If you extend / enhance / add menus in desktop distributions it is a great
feature but you should inform the others that it will be soon available.
Technical documentation people can write help about it, testers can test it and
so on.

Do you agree?

See also for further information:
http://wiki.services.openoffice.org/wiki/Category:Specification#I_Want_to_Change_Something_in_OpenOffice.org_-_Do_I_Have_to_Write_a_Software_Specification.3F

Jsi,

Can you help me find the information/documentation that was prepared for the
inclusion of:
openoffice-suse-menus
openoffice-redhat-menus
openoffice-debian-menus

This way I can adopt it for openoffice-slackware-menus without reinventing the
wheel.

BTW:
Do you think that this feature can be classified as:
    * The changes are not going to be integrated into the OpenOffice.org master.?

superandrzej I have no objections wrt to changing the name to the one with dashes.

Will do the change and then write specification & a feature mail (hopefully I'll
succeed in that - at least I already found the "button" in EIS for that....)

Created attachment 38219 [details]
testcase document as required by the specification process

setting to fixed again.

jsi: I think you missunderstood me. You argued that the other integrations also
do not have a spec. I understood it. Writing an announcement in EIS that there
will be something better for slackware is a minimum. Your changes to the code
will be noticed and can be tested. Can you agree on that?

cloph,

Can I help you somehow with the required documentation?

> Can I help you somehow with the required documentation?

AFAICT everything seems to be OK with the docs. I'm currently waiting for
feedback on the spec I wrote.
http://specs.openoffice.org/installation/native_installer/Slackware-desktop-integration.odt
(Feedback so far is: If nobody objects to it, it is OK)

I checked 2.0.4rc3 package but there is still no openoffice.org-slackware-menus
 inside. Is it going to make it for 2.0.4?

Haven't we already missed the deadline?

There is a little fix that could be delayed, the package works.


If there's the possibility of integrating it under 2.0.4, I give the QA approval
(I'm the QA member who CWS'ed it).


Well... it's up to Cloph and Joost now.

Just to mention, the issue is that the package description doesn't show up.

I haven't seen the final package but I'm guessing that the problem is that the
name of the package is not in line with the beginnings of lines in slack-desc file.
I asked cloph in July to rename the package name from
openoffice.org_slackware_menus into openoffice-slackware-menus so that the
naming pattern is just like in cases of other menus packages.
Back then I also mentioned about this dependency.

reopen.

slackware's package tools are so crappy...
When you create the package with a version other than tar-1.13, then the tools
cannot cope with it.

When the files are included like this:
./dir/file
./dir/file2

the tools cannot extract the description, since it tries to do 
"tar -zt install < packagefile"
which fails, since it would have to specify "./install" in this case

When the files are listed like this:
dir/file
dir/file2

the tools can extract the description, but it creates an invalid file-list for
removal. (since it only checks whether there is one single line in the
content-list of the file matching "^./" - if not, then it assumes that all files
are prefixed with that. It doesn't even bother to check whether any file is
prefixed with that at all. (and that with the whitty remark of

    # Some dumb bunny built a package with something other than makepkg.  Bad!
    # Oh well.  Bound to happen.  Par for the course.  Fix it and move on...
    echo './' >> $ADM_DIR/packages/$shortname
    cat $TMP/$shortname | grep -v '^./$' | cut -b3- >> $ADM_DIR/packages/$shortname

It even has a grep-statement in the "fix broken package" part, but notice how
dumb this grep statement is? They echo it into the file only to exclue it
afterwards. - Instead of only applying the cut only to lines really starting with ./
And of course the useless use of cat award goes to the authors as well.

But enough of the rant - I circumvented this by first creating an empty tar
(with only "./" and then appending the other entries)...

changes committed → fixed again.

Created attachment 39739 [details]
new integration package

I've mentioned something before and I've forgotten...

It shows a warning telling couldn't find update-desktop-base.
I know it isn't a problem, but the message could be redirected to "/dev/null".

Well... as this isn't important I'm marking it as verified.

Now it shows the package's description and keeps installing and removing fine.

correct target

set target 2.2

Hi cloph,

With Slackware 12.0 the KDE installation path has changed from /opt/kde to /usr
Would it be possible to introduce this small change in to slackware-menu package
before OO.o 2.3?

thanks

Andrzej

Hi cloph,

Is it possible to introduce the small change I mentioned in previous post or new
bug has to be reported?

thanks

Andrzej

cloph: ping (target was 2.2 ;-).

Sorry for the late reply, some mail just slipped through :-(

I would have preferred a new issue, since that one originally was fixed already,
but now it doesn't matter anymore

The problem is: One would need two packages for slackware, right? Or is there a
way to handle this in the package format (I doubt it).

As suggested: I've opened new Issue 87345

I close this issue again, since it was reopened then continued in a seperate list.