adding --prefix support for RPM

[jkoppe]

I exposed prefix and build_sub_dir so the ERB can read these bits and manipulate the SPEC according to http://www.rpm.org/max-rpm/s1-rpm-reloc-prefix-tag.html. It's a pretty simple change, and I've used it to generate RPMs with and without the --prefix argument. Let me know if there's anything else you need!

[jordansissel]

Just an FYI: path.gsub(/^/, prefix) is probably better written as "#{prefix}/#{path}" or perhaps better File.join(prefix,path)

[jkoppe]

Those two options make more sense. Note though that prefix is either / or /something/like/this. And I'm also doing no validation on prefix -- I assumed it was already done elsewhere.

[jordansissel]

I am excited for relocatable package support! :)

[jordansissel]

will test this later this week and try to write some tests to verify rpm is happy with it, then push a new gem :)

[jkoppe]

@jordansissel: eta on this pull?

[jordansissel]

Ooh sorry. Will get on this ASAP and put a new release out! Thanks again
for this :)

-Jordan

On Friday, July 20, 2012, Jason Koppe wrote:

@jordansissel: eta on this pull?

---

Reply to this email directly or view it on GitHub:
#230 (comment)

[jordansissel]

This change broke a few tests, but the fixes were super easy.

I also changed it to use the File.join(prefix, path) as discussed.

Thanks again for this patch! :)

[jordansissel]

I also couldn't get this to work properly, though I could be messing something. Here's what I tried, roughly 'package /etc/motd in the prefix /usr/local, but be relocatable.`

% fpm -s dir -t rpm -n example --prefix /usr/local /etc/motd`
% rpm -qlp example-1.0-1.x86_64.rpm 
/usr/local/usr/local/etc/motd

/usr/local/ was present twice.

Yet, if I patch it slightly, making 'build_sub_dir' always return "BUILD" instead of "BUILD/{prefix}", I get:

# Corrected behavior, I think?
% rpm -qlp example-1.0-1.x86_64.rpm                                  
/usr/local/etc/motd
% rpm -qip example-1.0-1.x86_64.rpm | grep Relo
Relocations : /usr/local 
% sudo rpm -i --prefix /pants example-1.0-1.x86_64.rpm 
% rpm -ql example
/pants/etc/motd

[jordansissel]

Does the above behavior seem correct to you? If so, I"ll release with my patches.

[jkoppe]

I'm probably abusing some RPM standard here, but the double /usr/local is ok in our case:

--> rpm -qpl Indeed-Percona-Server-server-5.5.24-rel26.0.256.rhel5-1-x86_64.rpm
/usr/local/percona/mysql-5.5.24/etc/init.d/mysql
/usr/local/percona/mysql-5.5.24/etc/logrotate.d/mysql
/usr/local/percona/mysql-5.5.24/usr/bin/innochecksum
/usr/local/percona/mysql-5.5.24/usr/bin/my_print_defaults
/usr/local/percona/mysql-5.5.24/usr/bin/myisam_ftdump
/usr/local/percona/mysql-5.5.24/usr/bin/myisamchk
/usr/local/percona/mysql-5.5.24/usr/bin/myisamlog
/usr/local/percona/mysql-5.5.24/usr/bin/myisampack
/usr/local/percona/mysql-5.5.24/usr/bin/mysql_convert_table_format
/usr/local/percona/mysql-5.5.24/usr/bin/mysql_fix_extensions
/usr/local/percona/mysql-5.5.24/usr/bin/mysql_install_db
/usr/local/percona/mysql-5.5.24/usr/bin/mysql_plugin
/usr/local/percona/mysql-5.5.24/usr/bin/mysql_secure_installation
/usr/local/percona/mysql-5.5.24/usr/bin/mysql_setpermission
/usr/local/percona/mysql-5.5.24/usr/bin/mysql_tzinfo_to_sql
/usr/local/percona/mysql-5.5.24/usr/bin/mysql_upgrade
/usr/local/percona/mysql-5.5.24/usr/bin/mysql_zap
/usr/local/percona/mysql-5.5.24/usr/bin/mysqlbug
/usr/local/percona/mysql-5.5.24/usr/bin/mysqld_multi
/usr/local/percona/mysql-5.5.24/usr/bin/mysqld_safe
/usr/local/percona/mysql-5.5.24/usr/bin/mysqldumpslow
/usr/local/percona/mysql-5.5.24/usr/bin/mysqlhotcopy
/usr/local/percona/mysql-5.5.24/usr/bin/mysqltest
/usr/local/percona/mysql-5.5.24/usr/bin/perror
/usr/local/percona/mysql-5.5.24/usr/bin/replace
/usr/local/percona/mysql-5.5.24/usr/bin/resolve_stack_dump
/usr/local/percona/mysql-5.5.24/usr/bin/resolveip
...

For MySQL RPMs, we use a modified startup script which sets environment variables correctly so the /usr/local/.../usr/ stuff just works.

Perhaps this is a no-no for RPMs. I'm going on vacation this week and won't be spending any time thinking about this. I hotfixed fpm on a machine so we could get this functionality for now -- but lets hold off on this pull until we have some more time to chat (August)

[jordansissel]

Sounds reasonable to me! In the mean-time, I"ll try to find someone who uses relocatable rpms and see what their use cases are.