[Slackbuilds-users] Symlinks and AUTOMATIC removals

[Jeremy Hansen]

Sorry for the delay in responding! I started typing this up, got pulled
away, and forgot about it until now.

On Fri, Dec 27, 2024 at 12:49 AM Shahab Vahedi <list+sbo at vahedi.org> wrote:

> 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.
>

This seems like *a lot* of unnecessary work for something makepkg is
literally designed to account for and automate (which minimizes chances of
mistakes).

> 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> )
>

You'd throw something like @LIBDIR@ into the doinst.sh and then use sed at
the end of the SlackBuild to make the necessary adjustments:

sed -i "s|@LIBDIR@|lib$LIBDIRSUFFIX|g" doinst.sh

I honestly didn't know if something like this existed in the repo, but
doing a grep looking for sed commands adjusting doinst.sh files with a
case-insensitive grep of lib showed there are 14 packages out of 9500ish
scripts. You can find them using this command at the base of a cloned SBo
repo:

grep sed.*doinst\.sh */*/*.SlackBuild | grep -i lib

To compare, if you grep SlackBuilds for "ln -s" and remove results
containing "man" (since the templates include a search to link manpages to
their newly compressed versions), that nets over 1000 results. It seems it
is much more common to create any required symlinks within the PKG
directory using the SlackBuild and let makepkg handle the automation of
removing them and adding them to the doinst.sh.

Digging into this more, there is a use case for specifying the
LIBDIRSUFFIX in the doinst.sh template, but this is for rebuilding the
gio cache if modules have been added there. There isn't a way to handle
this inside the SlackBuild, and the doinst.sh needs to know whether the
files are stored in /usr/lib/ or /usr/lib64/. You're still able to manually
specify your symlinks in the doinst.sh, but I really think it's better to
just let makepkg handle them. Choice is up to you!

Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20241231/c8ce2eb5/attachment-0001.htm>