You are not logged in.

#1 2018-03-27 12:35:46

tydell
Member
From: actually: Hannover, DE
Registered: 2009-07-26
Posts: 109
Website

Working with .install file

Hello.

I have a question about .install file. I have a package that  source code doesn't need to be compiled so I would like after package installation add path to my app .bashrc|.zshrc|.whateverrc depending on shell used by the user.

My post_install looks like this:

echo "export PATH=\$PATH:\/opt/my_package" >> /home/$USER/.$(echo ${SHELL##*/})rc
source /home/$USER/.$(echo ${SHELL##*/})rc

post_remove:

sed -n -i '/my_package/!p' /home/$USER/.$(echo ${SHELL##*/})rc
source /home/$USER/.$(echo ${SHELL##*/})rc

Unfortunately there is a problem, that it is trying to edit /root/.bashrc instead of user's .bashrc.
How can it be defined, that it always the user's file is edited?

Offline

#2 2018-03-27 12:48:45

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,449
Website

Re: Working with .install file

No.  Stop.  Absolutely do not try to modify user's configs.  Ever.

You could print a message telling the user where the executable is - but even this is a bit silly, they know how to find it, they installed it.

But if you maintain the package, why are you installing to /opt in the first place?  You shouldn't be.

EDIT: is this for "clickable"?  If so, you shoud request that upstream make it a proper python package which would make it trivial to install on any distro/OS.  But until then, you can put any needed content under /usr/lib and/or /usr/share/clickable and put the executable in /usr/bin where it belongs.

Last edited by Trilby (2018-03-27 12:54:41)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#3 2018-03-27 12:54:46

progandy
Member
Registered: 2012-05-17
Posts: 5,184

Re: Working with .install file

Never modify a user /home. You can only add the path globally in /etc/profile.d by adding a script. You don't need a .INSTALL file for that. Some examples are /etc/profile.d/jre.sh or /etc/profile.d/perlbin.sh. The user will have to do a fresh login or add the path manually to the current session.

Trilby is right, though. If you can adapt the package to the default locations, all the better. Even if that is not possible, a simple symlink from /usr/bin/ to the executable in /opt should work just as well.


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#4 2018-03-27 13:09:38

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Working with .install file

In the very worst of cases you should still create a wrapper script in /usr/bin which does any setup needed then executes the full path directly. But this package sucks and needs to act like all other software ever. It isn't the fault of the software, it is the terrible PKGBUILD which assumes /opt is necessary at all.

The whole thing is one single python script, you should simply install the one script to /usr/bin instead of the total trash involved in copying the Debian packaging and the scripts for building the .deb using docker and the readme and the online documentation sources etc. etc. ad nauseam.

Upstream sucks for suggesting by default to clone the whole repo and add it to the path for one script, and your PKGBUILD sucks for blindly listening to instructions which clearly do not apply to system packaging (and are not used in their Debian packaging).

Last edited by eschwartz (2018-03-27 13:10:38)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#5 2018-03-27 13:13:46

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,449
Website

Re: Working with .install file

Don't hold back, tell us how you really feel. tongue


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#6 2018-03-27 13:17:45

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Working with .install file

Well, I think this really is the most inventively redundant reason for someone trying to use post_install scripts to modify the user's $HOME, which I have ever seen. This despite seeing one which "cleaned up after itself" by deleting your Firefox profile in order to remove the Firefox extension it initially installed to $HOME instead of /usr/lib/firefox/browser/extensions/ .


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#7 2018-03-27 13:22:29

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,449
Website

Re: Working with .install file

Oh, I agree on the content of your post.  I'm just thinking of "catching more flies with honey" - of course if you just want the flies to drop dead and/or fly away, you're on the right track.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#8 2018-03-27 13:29:46

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Working with .install file

I'm grumpy from seeing too much destruction tongue post_install scripts which modify $HOME trigger me something terrible.

But it's the PKGBUILD which is terrible, there's nothing wrong with @tydell except for the need for a learning opportunity, so I guess there's that.

*takes deep breaths into a paper bag*


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#9 2018-03-27 17:03:03

tydell
Member
From: actually: Hannover, DE
Registered: 2009-07-26
Posts: 109
Website

Re: Working with .install file

Trilby wrote:

EDIT: is this for "clickable"?  If so, you shoud request that upstream make it a proper python package which would make it trivial to install on any distro/OS.  But until then, you can put any needed content under /usr/lib and/or /usr/share/clickable and put the executable in /usr/bin where it belongs.

Yes, it is for clickable. I thought to make an additional executable file as you described.

I asked for solution because I wanted to take advantage of the experience of more advanced in AUR/packages topic users.

Trilby wrote:

You could print a message telling the user where the executable is - but even this is a bit silly, they know how to find it, they installed it.

Currently it works that way, so first I did it with printable message. I think that people don't read such messages after installing package,

progandy wrote:

Never modify a user /home.

I am aware of the resulting risks, so I will not do it.

Thank you all for the answers, thanks to this I have more knowledge in this topic. I will try to do it the right way now.

Offline

#10 2018-03-27 19:12:28

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,449
Website

Re: Working with .install file

tydell wrote:

I thought to make an additional executable file as you described.

That's not really what I described.  There is no need to make an additional executable, just install the executable where it belongs.  And as Eschwartz points out, most of that repo is unnecessary (maybe all).  Just copy what is needed.  install/copy the script to /usr/bin, install/copy and valuable documentation to /usr/share/, leave all the other nonsense be.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

Board footer

Powered by FluxBB