[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rpmorg-list
Subject:    RE: packaging up a bunch of files
From:       "Lisa Alfieri" <lalfieri () gotuit ! com>
Date:       2006-02-07 19:24:44
Message-ID: auto-000032232962 () connactivity ! com
[Download RAW message or body]

Hi All-

I hope you're feeling generous again today! :-)

I've created my spec file (see below) and tried rpmbuild -b (friend of mine
works at Red Hat and that's what he uses) from /usr/bin

The spec file is in /usr/bin/SPECS and the usageclent.tar is in
/usr/bin/SOURCE

When I ran rpmbuild -b I received the following error:

[root@build-server bin]# rpmbuild -b usageclient_2.0.1.4.rpm
-b: unknown option


Unfortunately, no one at this company has experience creating RPMs and we
don't have any existing files for me to look at and try to emulate.

I appreciate any help you can give...

Lisa Alfieri

[root@build-server SPECS]# more usageclient.spec
Summary: Usage Client
Name: usage_client
Version: 2.0.1
Release: 4
License: GPL
Group: application
Source0: usageclient.tar
BuildArch: noarch
Vendor: Lisa

%description
RPM Package of Usage Client

%prep
cd $RPM_BUILD_ROOT
mkdir -p usageclient
tar xzvf $RPM_SOURCE_DIR/usageclient.tar

%build
make

%install
make install

%files
%defattr(-,root,root)
/produser/prod

-----Original Message-----
From: rpm-list-bounces@redhat.com [mailto:rpm-list-bounces@redhat.com] On
Behalf Of Nicolas Mailhot
Sent: Monday, February 06, 2006 5:17 PM
To: RPM Package Manager
Subject: RE: packaging up a bunch of files

Le lundi 06 février 2006 à 16:33 -0500, Lisa Alfieri a écrit :
> Joe-
> 
> I'm trying to do something similar and was wondering if you were
successful
> in your attempt.
> 
> I've never created a RPM before and am not having any luck. 
> 
> The build process at my company is very simple, label, checkout label, ant
> clean and ant. The ant puts files in a directory called "deploy".
Currently
> I'm tarring up the deploy directory.

You have a boatload of java spec file samples that use ant on 
http://www.jpackage.org/cgi-bin/viewcvs.cgi/rpms/free/?root=jpackage&only_wi
th_tag=JPACKAGE-1_7

The jpackage-discuss list may be helpful too

> The goal is to package up deploy and depending on whether this is a new
> install or an update, prompt the user for whether or not they want to
> overwrite the directory /deploy/config (there are only two files in this
> subdir).

This won't really work. rpm is designed to be non-interactive (and users
like it this way). You have several strategies available to handle your
problem :
1. you can mark these two files so rpm will either replace them by
default, keeping a backup of the old version, or leave them alone,
putting the new version next to them (%config(noreplace) and friends.
2. you can wrap rpm call in a script that will take care of user
interaction
3. you can include a setup script inside the rpm that the user can
invoke after install to perform interactive configuration

1. is the simplest option, people are used to it, and if you carefully
think about your use case you can choose a replacement strategy that
will work for most of your users.

> The last bit of information is, these files are owned by produser.prod on
> the build machine and we'd like them to be deployed as such.

%defattr

> My setup seems rather disjointed 

It's ok. On Linux files are not sorted by application roots (like dos,
mac or java) but ventilated all over the filesystem depending on their
properties (config, user, safe-to-look, must-backup and so on:
http://www.pathname.com/fhs/pub/fhs-2.3.html). Utilities like rpm help
to manage sets of related files located in different parts of the
filesystem

(do not build rpms as root, see the "initial setup" part on
http://www.jpackage.org/rebuilding.php)

Don't panic, try to rebuild an existing srpm which is close to your
needs, then take a look at its spec file contents and it'll become
clearer. 

-- 
Nicolas Mailhot



[prev in list] [next in list] [prev in thread] [next in thread]