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_with_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
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
