New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide `upgrade` action for packages #661

Closed
jordansissel opened this Issue Mar 10, 2014 · 18 comments

Comments

Projects
None yet
5 participants
@jordansissel
Owner

jordansissel commented Mar 10, 2014

Currently fpm provides --before-install and other things. Only install and remove are supported

Many packaging systems (rpm, arch, deb) support additional states, such as upgrade. They all implement them differently, but fpm can provide the right abstraction and templating to make it all work

In this ticket, it would be useful to track the ongoing work to provide an additional upgrade step.

It's also worth noting that by implementing this, we may cause behavioral changes. For example, if today a user knows that --after-install equates to postinst in deb, and wants to support upgrades, so the user carefully crafts a script to pass to --after-install and knows deb will handle it in a special way for upgrades. If we abstract install and upgrade scripting, we might accidentally mess up this existing behavior for this user.

@djhaskin987

This comment has been minimized.

Contributor

djhaskin987 commented Mar 10, 2014

Perhaps we use new arguments: --on-upgrade, --on-install, --on-remove. Make the distinction that these are upgrade/non-upgrade aware.

@djhaskin987

This comment has been minimized.

Contributor

djhaskin987 commented Mar 10, 2014

Also: --before-upgrade, --before-install, --before-remove. If they really perform well, we could deprecate the old options.

@djhaskin987

This comment has been minimized.

Contributor

djhaskin987 commented Mar 10, 2014

Here is the format in a SPEC file for install, upgrade, and remove cases:

%pre

if [ "${1}" -eq 1 ]
then
    # "before install" goes here
elif [ "${1}" -gt 1 ]
then
    # "before upgrade" goes here
fi

%post

if [ "${1}" -eq 1 ]
then
    # "On install" goes here
elif [ "${1}" -gt 1 ]
then
    # "On upgrade" goes here
fi

%preun

if [ "${1}" -eq 0 ]
then
    # "before remove" goes here
else
    # This category is unnamed. It represents the case where an upgrade is
    # happening, and before the old package is being removed.
    # It may be the case that this case is largely unused, which is
    # probably why ARCH only has install, remove, and upgrade cases.
fi

%postun

if [ "${1}" -eq 0 ]
then
    # "on remove" goes here
elif [ "${1}" -gt 0 ]
    # This category is unnamed. It represents the case where an upgrade is
    # happening, and after the old package is being removed.
    # It may be the case that this case is largely unused, which is
    # probably why ARCH only has install, remove, and upgrade cases.
fi
@djhaskin987

This comment has been minimized.

Contributor

djhaskin987 commented Mar 10, 2014

A comprehensive guide for how debian scripts and their options, and what is called when on install, remove, and upgrade cases: https://wiki.debian.org/MaintainerScripts

@djhaskin987

This comment has been minimized.

Contributor

djhaskin987 commented Mar 10, 2014

Possible first-hack at the debian scripts for install-upgrade-configure:
preinst

if [ "${1}" = "install" -a -z "${1}" ]
then
    # "before install" goes here
elif [ "${1}" = "upgrade" -a -n "${2}" ]
then
    upgradeVersion="${2}"
    # "before upgrade" goes here
elif [ "${1}" = "install" -a -n "${2}" ]
then
    upgradeFromVersion="${2}"
    # executed when a package is removed but its config files aren't,
    # and a new version is installed.
    # looks a _lot_ like an upgrade case, I say we just execute the
    # same "before upgrade" script as in the previous case
elif echo "${1}" | grep -E -q '(fail|abort)'
then
    # fail with error message
    # maybe some debug output
fi

postinst

if [ "${1}" = "configure " -a -z "${2}" ]
then
    # "on install" here
elif [ "${1}" = "configure" -a -n "${2}" ]
then
    upgradeFromVersion="${2}"
    # "on upgrade" here
    # NOTE: This slot is also used when deb packages are removed,
    # but their config files aren't, but a newer version of the
    # package is installed later, called "Config-Files" state.
    # basically, that still looks a _lot_ like an upgrade to me.
elif echo "${1}" | grep -E -q "(abort|fail)"
then
    # fail with error message
fi

prerm

if [ "${1}" = "remove" -a -z "${2}" ]
then
    # "before remove" goes here
elif [ "${1}" = "upgrade" ]
then
    upgradeVersionTo="${2}"
    # Executed before the old version is removed
    # upon upgrade.
    # Maybe we just do nothing here.
elif echo "${1}" | grep -E -q "(fail|abort)"
then
    # Something went wrong, fail with error message
fi

postrm

if [ "${1}" = "remove" ]
then
    # "on remove" goes here
elif [ "${1}" = "purge" -a -z "${2}" ]
then
    # like "on remove", but executes after dpkg deletes config files
    # 'apt-get purge' runs 'on remove' section, then this section.
    # Maybe we ignore this; it seems really fine-grained.
    # There is no equivalent in RPM. A debian-specific argument
    # might perhaps be used here, but most people
    # probably don't need it.
elif [ "${1}" = "upgrade" ]
then
    # This represents the case where the old package's postrm is called after
    # the 'preinst' script is called.
    # Maybe we ignore this and just use 'preinst upgrade' and
    # 'postinst' configure'
elif echo "${1}" | grep -E -q '(fail|abort)'
then
    # something went wrong, print error message
fi
@wohali

This comment has been minimized.

wohali commented Aug 26, 2014

Any progress on this? The first pass hack above would be sufficient for our needs.

@djhaskin987

This comment has been minimized.

Contributor

djhaskin987 commented Aug 27, 2014

I can start working on it if no one else chimes in, probably today. :)

@jordansissel

This comment has been minimized.

Owner

jordansissel commented Aug 27, 2014

+1 on the idea.

@djhaskin987 Thank you for providing these excellent templates for deb and rpm!

@jordansissel

This comment has been minimized.

Owner

jordansissel commented Aug 27, 2014

@djhaskin987 happy to have you work on it if you can; let me know if you have questions on anything inside fpm and I'll do what I can to get you good info :)

@djhaskin987

This comment has been minimized.

Contributor

djhaskin987 commented Sep 12, 2014

I have begun work on this issue here:
https://github.com/djhaskin987/fpm/tree/feature/661
I have so far added the options needed in command.rb . Now trying to integrate RPM into this mess :P.

@djhaskin987 djhaskin987 referenced this issue Sep 19, 2014

Merged

Feature/661 #772

@djhaskin987

This comment has been minimized.

Contributor

djhaskin987 commented Sep 19, 2014

Made a pull request, @wohali @jordansissel . Please look over it and tell me if you have questions! :)

@djhaskin987

This comment has been minimized.

Contributor

djhaskin987 commented Oct 16, 2014

@jordansissel any movement on this issue?

@jordansissel

This comment has been minimized.

Owner

jordansissel commented Oct 16, 2014

I should totally merge #772, eh? I'll try and do that in the next few days.

@jordansissel

This comment has been minimized.

Owner

jordansissel commented Oct 16, 2014

MERGED! :P

@djhaskin987

This comment has been minimized.

Contributor

djhaskin987 commented Oct 16, 2014

YAY! thx

@wohali

This comment has been minimized.

wohali commented Oct 18, 2014

TYVM.

@josegonzalez

This comment has been minimized.

Collaborator

josegonzalez commented Aug 18, 2015

So this can be closed?

@djhaskin987

This comment has been minimized.

Contributor

djhaskin987 commented Sep 12, 2017

I believe this can be closed, it has been released and live for some time now :) thanks to all who helped

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment