[Slackbuilds-users] Symlinks and AUTOMATIC removals

Shahab Vahedi list+sbo at vahedi.org
Fri Dec 27 08:52:15 UTC 2024


[ +cc SBo list ]

December 27, "Jeremy Hansen" wrote:
 
> Do you have an example package where this occurred?

Here, I am using "&&" to break out of the "( cd <path> ; rm -f <file> )"
pattern in "doinst.sh":

https://git.slackbuilds.org/slackbuilds/tree/system/brother-brscan4/doinst.sh?h=e3fa7302a#n20

The counter removal part is in "douninst.sh" because now those "symlinks"
are not handled automatically anymore:

https://git.slackbuilds.org/slackbuilds/tree/system/brother-brscan4/douninst.sh?h=e3fa7302a#n2

On the conterary, having the "( cd <path> ; rm -f <file> )" for these
particular symlinks results in _automatic_ removal, so no "douninst.sh"
section is necessary:

https://git.slackbuilds.org/slackbuilds/tree/system/brother-brscan4/doinst.sh?h=e3fa7302a#n34

This is desired as I want the empty "/etc/opt/brother/" dir be removed
after uninstalling the package.

> I can't think of a reason why the doinst.sh should have $LIBDIRSUFFIX in it
> (but maybe there's edge cases I can't think of). Symlinks generally
> (always?) should be created within the package directory structure by
> commands in the SlackBuild, which will replace $LIBDIRSUFFIX with the
> correct location in that directory structure.
> 
> Then, when makepkg is ran, it will remove symlinks and add them
> automatically to the doinst.sh.

My whole point of adding things to "doinst.sh" was to avoid the warning
(probably "warning" is too strong of a word) from "makepkg". I wanted to
make things explicit.

> If there is really a reason to manually add symlinks to the doinst.sh, a
> sed command should be used to ensure the correct directory is listed in the
> final doinst.sh before the makepkg is ran.

Could you provide the name of a package who does this?

It's all good if we figure out that I did not package "brother-brscan4"
as it should have been. I'm open to fixing that. HOWEVER, the point of my
original e-mail was if anybody knows about this _undocumented_ behaviour?
And by that, I mean that there is a "contract" on constructs like below:

  ( cd <path> ; rm -rf <file> )
  ( cd <path> ; ln -sf <src> <file> )

--
Shahab


More information about the SlackBuilds-users mailing list