Info about mandatory steps to perform by user before update/install

wreiner · 2018-02-11 13:15:44

What is the best way to let users know of mandatory steps to take before updating or installing a new version of an AUR package?

Background is, that packages of mine need the user to manually export data using the old package version because of changes in the software itself which are breaking backward compatibility.
Problem is, if I just run the installation, the old version will get uninstalled and the necessary tasks cannot be performed anymore.

My first approach is that I already added an upgrade notice in the packages .install-file for the pre_install and pre_upgrade hooks but those are only messages.
Second thing I could think of to maybe add the information to the packages CHANGELOG file but only messages again.

Trilby · 2018-02-11 13:20:53

Where is this data that needs to be exported? If it is system-wide data, you might be able to do the export from the pre_install function. If it is user data under /home/ that certainly wouldn't work.

Even if it is system-wide, this should be an opt-in: the pre_install may be able to prompt the user to accept the changes (I'm not sure whether pre_install scripts are allowed to be interactive).

Another part of me just thinks you should put a big comment in the PKGBUILD. AUR users should be looking at the PKGBUILDs before building... in theory.

Last edited by Trilby (2018-02-11 13:22:51)

wreiner · 2018-02-11 13:33:14

Thanks for the reply.

I've looked into interactive .installs and the consensus is, that this is a bad idea and should be avoided.

The data is per user and is password protected so the steps are to be taken manually unfortunately.

A information in AUR is a good idea too - thank you for this suggestion!

EDIT: oh sorry, you meant in the PKGBUILD file itself - like with a commented out line at the beginning?

Last edited by wreiner (2018-02-11 13:36:17)

Trilby · 2018-02-11 13:43:28

I was being partially facetious about the comment in the PKGBUILD. I definitely think it's a good idea. User are *supposed* to read PKGBUILD before building them. So if users did what they were supposed to, that would be sufficient.

However, many will not even look at the PKGBUILD before rebuilding. So to save yourself the headache, you would want to make it much more obvious. I suspect a message blast on every relevant outlet would be good: an obvious comment in the PKGBUILD (near the top, perhaps with a bit "IMPORTANT" or some such), in the AUR comments, and a final warning in the pre-install message telling the user to abort the upgrade and read the PKGBULD comments if they've not already exported the data.

As a packager, you do want to make it as easy as practical for users to handle such things properly. But in the end, the user is the only one responsible for their AUR packages. The above efforts to get the message out should reach every reasonable/responsible user of the software, and at that point the unreasonable or irresponsible are really not your concern.

Last edited by Trilby (2018-02-11 13:46:45)

wreiner · 2018-02-11 14:06:18

Thank you for your suggestions, I think you're right.

I'll blast my message out on all channels this should be enough. The comment on the packages AUR page and using the CHANGELOG also keeps the history.

eschwartz · 2018-02-11 17:27:45

Putting a notice in the AUR comments and PKGBUILD and echoing the message at install time seems like a reasonable "covering all bases" approach. If worst comes to worst, the user will see the notice during the installation and have the ability to rollback the package to a previous version (assumes they keep a package cache of installed AUR packages, which everyone should).

(I will note that as a rule messages are not supposed to be emitted during makepkg, due to the fact that the built package can be served in a custom repo and won't show the message, or the package can be built once and then actually installed some time later after the message is forgotten. This is of course complicated by the need to have user intervention *before* the upgrade.)

wreiner · 2018-02-11 17:36:18

Thank you!

The multiple install thing I tried to cover with the message in the .install file, this is packaged with the package so it is shown if reused too, but maybe too late.

ngoonee · 2018-02-11 19:08:45

If you're the developer for the application, a user-friendly way to handle this would be to check on your app start-up whether there's old incompatible data and if so back it up in a fixed location. This eases the packager's job, as now you just need a post-install message along the lines of "this update is data-incompatible, please downgrade before running in order to export your old data. If you forgot to do so and your old data was wiped, please manually restore the backup at <location>"

eschwartz · 2018-02-11 19:23:34

If one has the advantage of being the upstream developer, surely the best way to handle this is to include migration code or a migration tool in the software itself...

ngoonee · 2018-02-12 02:26:13

Eschwartz wrote:

If one has the advantage of being the upstream developer, surely the best way to handle this is to include migration code or a migration tool in the software itself...

Would only work if it was automatic though. E.g. postgres upgrades aren't, simply because user intervention will likely be required in any case.

eschwartz · 2018-02-12 02:47:17

I'm not sure I understand what you mean. Surely the purpose of a migration tool is that it doesn't require running the *old* version of the software, after you've already upgraded to the *new* version.

And naturally, a migration "tool" would be guided by the user as an alternative to code in the software itself which autoconverted the data. I'm not sure where I implied this wasn't an option.

ua4000 · 2018-02-17 13:37:50

Fixing/updating the tool with a migration "helper" is the best way of course, but having something similar to "www.archlinux.org/news/" incl. RSS for AUR related important things would be a fine idea too...

Trilby · 2018-02-17 14:45:29

ua4000 wrote:

having something similar to "www.archlinux.org/news/" incl. RSS for AUR related important things would be a fine idea too...

You mean like comments on AUR packages. I bet that can be put together pretty quickly ... there, it's done.

progandy · 2018-02-17 18:35:00

The AUR has even pinned comments, so that you as the maintainer can pin important messages. You can read the comments from the shell as well with e.g. aur-comment-fetch

Edit: Since you should read a PKGBUILD before creating the package, a comment in the file should work as well.

Last edited by progandy (2018-02-17 18:40:18)

Arch Linux

#1 2018-02-11 13:15:44

Info about mandatory steps to perform by user before update/install

#2 2018-02-11 13:20:53

Re: Info about mandatory steps to perform by user before update/install

#3 2018-02-11 13:33:14

Re: Info about mandatory steps to perform by user before update/install

#4 2018-02-11 13:43:28

Re: Info about mandatory steps to perform by user before update/install

#5 2018-02-11 14:06:18

Re: Info about mandatory steps to perform by user before update/install

#6 2018-02-11 17:27:45

Re: Info about mandatory steps to perform by user before update/install

#7 2018-02-11 17:36:18

Re: Info about mandatory steps to perform by user before update/install

#8 2018-02-11 19:08:45

Re: Info about mandatory steps to perform by user before update/install

#9 2018-02-11 19:23:34

Re: Info about mandatory steps to perform by user before update/install

#10 2018-02-12 02:26:13

Re: Info about mandatory steps to perform by user before update/install

#11 2018-02-12 02:47:17

Re: Info about mandatory steps to perform by user before update/install

#12 2018-02-17 13:37:50

Re: Info about mandatory steps to perform by user before update/install

#13 2018-02-17 14:45:29

Re: Info about mandatory steps to perform by user before update/install

#14 2018-02-17 18:35:00

Re: Info about mandatory steps to perform by user before update/install

Board footer