Ticket #1499 (Closed: wontfix)

John, please check in this patch to the branch named CAMPSITE_2_3_BRANCH (full path: svn://code.campware.org/campsite/branches/CAMPSITE_2_3_BRANCH/campsite). I think a regular RPM build for each release is worth the extra risk of the build failing on some architecture. This patch doesnt look too complicated anyhow. Please contact me on IM before you do this.

I read a little bit about this RPM how to and found out that this patch is not needed. Please read: http://www.rpm.org/max-rpm/ch-rpm-build.html and http://www.rpm.org/max-rpm/ch-rpm-rw-build.html

Use %files directive. There are other open source projects not built specificaly for RPM and still you can build RPM packages from them without modifying the install scripts.

This patch only makes the install scripts more complex without adding any functionality.

Hi Mugur

I'm afraid that's really not going to work. Campsite's installer runs a lot of scripts as part of its install process, and these scripts don't output nice clean lists of the files that they've created. Using the %files directive is great if you know with 100% confidence where your files are going to be, but normally (ie in EVERY spec file I've actually seen in practise) you want to use a BuildRoot?.

Why? * you can build as non-root user, ensuring that you can't accidentally mess up an already-running installed version of the software while building the RPM for the new version * you can't accidentally scatter files around on your root file system and then forget you left them there * you can ensure that all files are packages, because RPM can examime the BuildRoot? and check that all files found are present in the RPM

Please, can we just do the patch? It's necessary complexity. We're only talking about sticking $BUILD_ROOT before installed file paths.

Here are my reasons why I reject this patch: 1. The RPM package can be built without this patch; RPM doesn't need a BUILD_ROOT directory (see my previous comment on RPM how to). 2. It makes the install scripts more complex and hard to maintain. 3. It can't be applied on the 2.4 branch because the install scripts there changed a lot, some files were moved. This means that the whole work has to be done from the beginning. 4. The file list can be easily generated, see https://www.campware.org/projects/campsite/wiki/HowToBuildRPMPackage 5. I'm not willing to spend more time on these install scripts which will be discarded anyway.

Here another reason: 6. Campsite can already be installed by a non-root user, so in this respect there is no gain to apply this patch.

It won't work.

You *can* install Campsite as a non-root user, but if you do that, then all the configuration files will refer to the non-root file locations.

In order to install Campsite non-root with the configuration files correctly referring to the on-root (final, installed) file locations (which are not the same as the non-root file locations), you must apply the patch I gave you.

Your approach will only work as root user, and it will destroy my currently-running working version of campsite, so I'm not willing to use that approach.

JP

John, it seems it's a missunderstanding. You can install Campsite as a non-root user and USE it. This is not for creating a RPM package.

I modified the file list generating script and you can install Campsite in /usr/local/campsite-rpm directory (see https://www.campware.org/projects/campsite/wiki/HowToBuildRPMPackage) so you won't ruin your existing installation.

As for building the RPM package as a non-root user that doesn't justify applying the patch, IMHO it's not an issue that you need to be root in order to build the package.

Indeed it does seem that there is a misunderstanding. Let me try to explain again.

I know I can install campsite as a non-root user. This means installing it in ~john/campsite-local or someplace like that.

If I install campsite in /usr/local/campsite-rpm then obviously I need to be root since that is a privileged directory.

If I do install there, then I will run the campsite installer script and all of the configuration files will be hard-wired with references to /usr/local/campsite-rpm.

This means that the files in my campsite RPM would have to be finally installed to run from that location, which is not what I want. I want to use default file locations: /usr/share/campsite, /var/www, /etc, and so on, for all the files.

This is not possible with the method you propose, since the CONTENTS of the generated configuration files will be HARD-WIRED WITH REFERENCES TO THE /usr/local/campsite-rpm path which was used during the installer phase.

The standard approach used by autoconf/automake scripts is to have command line parameters allowing all of the file locations to be specified when you type 'make' and 'make install'. In the case of normal RPM builds, DIFFERENT FILE LOCATIONS are specified when it runs 'make' (eg make --etc-dir=/etc) from when it runs 'make install' (eg make --etc-dir=/tmp/rpm/etc). This is required so that the built files internally refer to their as-installed locations, but then the installer is installing those files to a temporary location so that (a) they can be collected later, (b) root privileges aren't required to build the RPM (c) existing software can't be overwritten accidently by root privileges messing up stuff.

I have build a dozen or more RPMs now for different softwares. Please either try to do this completely start-to-finish by yourself, because I really don't believe your approach is right, or accept the patch. I've spent enough time on this.

You say that this patch is unnecessary complexity. This is a case of making the best of the system we have currently: a collection of handwritten highly complex bespoke makefiles and shell scripts. Perhaps one day we can move to an automake/autoconf-style installer. But for now, we have to hack.

You have to install Campsite to /usr/local/campsite-rpm ONLY to retrieve the files list, NOT to make a RPM package from it!!!

Did you take a look at the script generate_files_list.php? Did you run it? I suppose not. If you would have tried it you could see the output list which is generic:

%campsitedir
%_bindir
%_bindir/cli_script_lib.php
...
%_sysconfdir
%_sysconfdir/parser_conf.php
...
%campsitewww
%campsitewwwcommon
%campsitewwwcommon/html
...

and so on. After you get the files list add it to the RPM spec file and build the RPM AS BEFORE. What I gave you is JUST a method to retrieve the files list. Now if you put that file list under %files directive the RPM tool will know how to build the package and will remove them when the build was done.

Please do not reopen this issue, I won't apply the patch because I know you can build the RPM without it. In case you want to exchange more opinions contact me on my email.