emerge --depclean

tHOM! · External Since: Jun 11, 2007 Posts: 6

Hello all !

I was wondering how "safe" the --depclean option to emerge really is.
Judging by the output of emerge --depclean it's not safe at all. Or am I
being paranoid ?

Lately I'm reading a lot about update procedures on Gentoo and people
usually suggest an emerge --depclean after something like emerge -DutNav
world amongst other things. However on my system this would have emerge
remove 124 of 328 installed packages which has me thinking twice
allowing it to proceed.

Although a revdep-rebuild would most probably fix the system in case it
breaks doing an emerge --depclean, I'm not so sure that it is such a
good idea in my case. Especially since after scanning the list of
packages to be removed, I'm pretty sure I've spotted some vital
packages. It would be the first time I every run an emerge --depclean on
this system. Does that maybe have something to do with emerge trying to
remove that many packages ?

If any of you has similar experience and I'm just being paranoid, let me
know. Right now I have serious doubts about running emerge --depclean.

Thank you !

Tom

Arthur Hagen · External Since: Aug 30, 2004 Posts: 524

tHOM! <thom DeleteThis @the-altered-states.de> wrote:
> Hello all !
>
> I was wondering how "safe" the --depclean option to emerge really is.
> Judging by the output of emerge --depclean it's not safe at all. Or
> am I being paranoid ?

No, you're not being paranoid. Before running --depclean, it really /is/
important to run an "emerge --update --deep --newuse world" /before/
the --depclean. Even if no useflags have changed, the --newuse /should/ in
theory rebuild when there's minor changes but no version bump.
However... It doesn't always detect them.
Sometimes ebuilds change in a way that --newuse won't pick them up either,
and then when you run --depclean, and the packages are to be removed, you
get an MD5 checksum mismatch, and the binaries/libraries aren't removed
after all. That leaves you with a system with installed files with no
owners, which might get out of date and with discovered security flaws and
no fixes (or even knowing that they need to be fixed).
The fix to this is to first /install/ every package
that --depclean --pretend tells would be removed, and then remove them. And
then re-install any packages with the same name but /higher/ version, in
order, because the correct logic to deal with multiple package versions or
removed package revisions is in the newer ebuilds.

Finally, there's some packages that get bumped but
which --update --deep --newuse fails to rebuild in a newer version.
cabextract is one such. To find these, I every now and then run:

emerge -pe world | grep '^[e' | grep -v '^[ebuild R ]'

Anything listed should be rebuilt before running a --depclean.

But following precautions, there's nothing much wrong with
running --depclean. It's a good idea to not have packages installed that
you won't use.

Regards,
--
*Art

tHOM! · External Since: Jun 11, 2007 Posts: 6

Arthur Hagen wrote:
> tHOM! <thom RemoveThis @the-altered-states.de> wrote:
>> Hello all !
>>
>> I was wondering how "safe" the --depclean option to emerge really is.
>> Judging by the output of emerge --depclean it's not safe at all. Or
>> am I being paranoid ?
>
> No, you're not being paranoid. Before running --depclean, it really
> /is/ important to run an "emerge --update --deep --newuse world"
> /before/ the --depclean. Even if no useflags have changed, the --newuse
> /should/ in theory rebuild when there's minor changes but no version bump.
> However... It doesn't always detect them.
> Sometimes ebuilds change in a way that --newuse won't pick them up
> either, and then when you run --depclean, and the packages are to be
> removed, you get an MD5 checksum mismatch, and the binaries/libraries
> aren't removed after all. That leaves you with a system with installed
> files with no owners, which might get out of date and with discovered
> security flaws and no fixes (or even knowing that they need to be fixed).
> The fix to this is to first /install/ every package that --depclean
> --pretend tells would be removed, and then remove them. And then
> re-install any packages with the same name but /higher/ version, in
> order, because the correct logic to deal with multiple package versions
> or removed package revisions is in the newer ebuilds.
>
> Finally, there's some packages that get bumped but which --update --deep
> --newuse fails to rebuild in a newer version. cabextract is one such.
> To find these, I every now and then run:
>
> emerge -pe world | grep '^[e' | grep -v '^[ebuild R ]'
>
> Anything listed should be rebuilt before running a --depclean.
>
> But following precautions, there's nothing much wrong with running
> --depclean. It's a good idea to not have packages installed that you
> won't use.
>
> Regards,

Hello !

That clears up some things over here but is it really necessary to
intall -> deinstall -> install(higher version) ? That's an awful lot of
trouble just to get rid of old dependencies (if any) don't you think ?
Besides what if there is no newer version of a package, or the package
is masked at the time I want to emerge --depclean, or even worse the
package has been removed completely ?

Anyhow, if I understand you correctly the second step is that you're
filtering the output of emerge -pe world to find occurrences of
[ebuild...] but not [ebuild R...] to see whether there are packages that
haven't been detected by an emerge --newuse --whatever ?

Regards,

Tom

Arthur Hagen · External Since: May 30, 2004 Posts: 45

On Tue, 2007-06-12 at 16:48 +0200, tHOM! wrote:
>
> That clears up some things over here but is it really necessary to
> intall -> deinstall -> install(higher version) ?

Actually, the flow is

Install
[Later decide you don't want it]
Reinstall same version (which may have different files)
Uninstall

> That's an awful lot of
> trouble just to get rid of old dependencies (if any) don't you think ?

It is, but it's still way less work than the alternatives, like creating
an overlay, and enter the MD5 checksums that the files /actually/ have
before uninstalling, or manually edit the pkg configuration files, or
(which would be best) educate the portage maintainers to NEVER EVER
update the Manifest with the checksums without also bumping the package,
or it won't uninstall cleanly. Since the maintainers don't tend to
uninstall the package they maintain, but just upgrade them, they never
see the problem themselves. It's just when you unmerge a package that
you get bit.

In addition to the security aspect (leaving around old binaries that
never will get patched because no-one knows they're there), doing an
emerge -C with warnings that leaves files is bad for a different reason:
Later, you may install a different package with the same binary names,
or even the same package that now installs to a different location.
And calling "foo" will then call the old /usr/bin/foo instead of the
new /bin/foo, which you may not even notice until things are broken.

> Besides what if there is no newer version of a package, or the package
> is masked at the time I want to emerge --depclean, or even worse the
> package has been removed completely ?

If there is no newer "version" (meaning instance, regardless of version
number), there is no problem. Then emerge -C will succeed.

> Anyhow, if I understand you correctly the second step is that you're
> filtering the output of emerge -pe world to find occurrences of
> [ebuild...] but not [ebuild R...] to see whether there are packages that
> haven't been detected by an emerge --newuse --whatever ?

Indeed. There sometimes are, unfortunately.

Regards,
--
*Art

Arthur Hagen · External Since: May 30, 2004 Posts: 45

On Wed, 2007-06-13 at 16:37 +0200, tHOM! wrote:

> I followed your suggestions and all went well.
>
> Thank you Art !

No problem. I noticed that I could depclean out libdb 1.x and 3.x now,
which was good. Especially db 1.85 had survived for way too long.

Incidentally, the behaviour of "grep" appears to have changed since I
wrote my post a few days ago. You used to have to use egrep (or grep
-E) to get [] matching, and normal grep would only do anchors (^$) and
simple wildcards. However, doing "grep '^[e' now gives an error:
grep: Unmatched [ or [^

Quick fix for finding packages that have been bumped but which "emerge
--update --deep --newuse world" won't find: escape the bracket or drop
it:

emerge -pe world | grep '^\[e' | fgrep -v ' R '

Regards,
--
*Art

tHOM! · External Since: Jun 11, 2007 Posts: 6

Arthur Hagen wrote:
> On Tue, 2007-06-12 at 16:48 +0200, tHOM! wrote:
>> That clears up some things over here but is it really necessary to
>> intall -> deinstall -> install(higher version) ?
>
> Actually, the flow is
>
> Install
> [Later decide you don't want it]
> Reinstall same version (which may have different files)
> Uninstall
>
>> That's an awful lot of
>> trouble just to get rid of old dependencies (if any) don't you think ?
>
> It is, but it's still way less work than the alternatives, like creating
> an overlay, and enter the MD5 checksums that the files /actually/ have
> before uninstalling, or manually edit the pkg configuration files, or
> (which would be best) educate the portage maintainers to NEVER EVER
> update the Manifest with the checksums without also bumping the package,
> or it won't uninstall cleanly. Since the maintainers don't tend to
> uninstall the package they maintain, but just upgrade them, they never
> see the problem themselves. It's just when you unmerge a package that
> you get bit.
>

I agree. All other options that you've pointed out are even more
cumbersome. You seem to know what you're doing so why don't you
"suggest" this to them ? I mean there's at least a chance that they
MIGHT listen.

> In addition to the security aspect (leaving around old binaries that
> never will get patched because no-one knows they're there), doing an
> emerge -C with warnings that leaves files is bad for a different reason:
> Later, you may install a different package with the same binary names,
> or even the same package that now installs to a different location.
> And calling "foo" will then call the old /usr/bin/foo instead of the
> new /bin/foo, which you may not even notice until things are broken.
>

Interesting thought. Depending on the order of the PATH entries, the
latter overloads the former entry and you may wind up calling the old
(left over after an unsuccesfull emerge -C ) binary, without even
knowing about it (Despite the warning message that emerge -C would have
spit out.). Depending on where the package installs it's files, it might
work out just fine for one package beacuse it installs the files to a
location defined later in the PATH variable and totally break things for
another package that installs files to a location defined earlier in the
PATH. Not good - not good at all.

>> Besides what if there is no newer version of a package, or the package
>> is masked at the time I want to emerge --depclean, or even worse the
>> package has been removed completely ?
>
> If there is no newer "version" (meaning instance, regardless of version
> number), there is no problem. Then emerge -C will succeed.
>

My mistake. Surely if there's no new version (instance), there's no new
manifest and no new checksum.

>> Anyhow, if I understand you correctly the second step is that you're
>> filtering the output of emerge -pe world to find occurrences of
>> [ebuild...] but not [ebuild R...] to see whether there are packages that
>> haven't been detected by an emerge --newuse --whatever ?
>
> Indeed. There sometimes are, unfortunately.
>
> Regards,

I followed your suggestions and all went well.

Thank you Art !

Regards,

Tom

Martin Vaeth · External Since: Jul 23, 2005 Posts: 44

Arthur Hagen <art RemoveThis @broomstick.com> wrote:
>
> It is, but it's still way less work than the alternatives, like creating
> an overlay, and enter the MD5 checksums that the files /actually/ have
> before uninstalling, or manually edit the pkg configuration files, or
> (which would be best) educate the portage maintainers to NEVER EVER
> update the Manifest with the checksums without also bumping the package,
> or it won't uninstall cleanly.

You are confusing something. When portage uninstalls a package,
it checks whether the *installed* files have been modified by
comparing its date/checksum with the data stored in /var/db/pkg/...
The checksums in the portage tree (Manifest files) have nothing to
do with this.

>> Besides what if there is no newer version of a package, or the package
>> is masked at the time I want to emerge --depclean, or even worse the
>> package has been removed completely?

In all these cases, emerge --depclean will remove the package.
And this is ok, because it means it is actually not needed by any other
package (and also you do not want it since otherwise you would have
entered it in your world file...). However, it might happen that in your
current system some package has been compiled against a library of
this package - in this case you have to recompile that package
(That's why the revdep-rebuild is necessary).

> If there is no newer "version" (meaning instance, regardless of version
> number), there is no problem. Then emerge -C will succeed.

This has nothing to do with a newer version.

>> Anyhow, if I understand you correctly the second step is that you're
>> filtering the output of emerge -pe world to find occurrences of
>> [ebuild...] but not [ebuild R...] to see whether there are packages that
>> haven't been detected by an emerge --newuse --whatever ?
>
> Indeed. There sometimes are, unfortunately.

It remains mysterious why one should want to find such packages.

tHOM! · External Since: Jun 11, 2007 Posts: 6

Martin Vaeth wrote:
> Arthur Hagen <art RemoveThis @broomstick.com> wrote:
>> It is, but it's still way less work than the alternatives, like creating
>> an overlay, and enter the MD5 checksums that the files /actually/ have
>> before uninstalling, or manually edit the pkg configuration files, or
>> (which would be best) educate the portage maintainers to NEVER EVER
>> update the Manifest with the checksums without also bumping the package,
>> or it won't uninstall cleanly.
>
> You are confusing something. When portage uninstalls a package,
> it checks whether the *installed* files have been modified by
> comparing its date/checksum with the data stored in /var/db/pkg/...
> The checksums in the portage tree (Manifest files) have nothing to
> do with this.
>

Let's see - Usually "/var/db/pkg/category/application" contains among
other files, the CONTENTS file that lists install path, name, md5
checksum + unix time for every file of that specific package. What does
the unix time stand for ? Is it the time of install or the time when the
file was created in the first place ?

Under "/usr/portage/category/application" is (among other files) the
Manifest, which contains rmd160, sha1 and sha256 checksums for each file
in that directory plus a gpg signature for the package. The complete
package ?

If I understand you correctly these checksums are not used in the
--depclean process (which makes sense because the Manifest does not
contain any checksum or date for a specific installed file). I assume
they are used to prove the authenticity of each file in that directory.
Those are checked against what ?

Assuming that your description of the process is correct and portage
checks date + checksum of each file to be removed. Against what are they
checked ? Since the only location where those checksums are found is the
CONTENTS file in "/var/db/pkg/category/application/CONTENTS". If portage
would only check the checksum, it can surely be calculated from the
installed file but you're saying that portage is checking the date as
well. I really wonder how, since as soon as I edit a config file for
example, this information changes in the file system.

>>> Besides what if there is no newer version of a package, or the package
>>> is masked at the time I want to emerge --depclean, or even worse the
>>> package has been removed completely?
>
> In all these cases, emerge --depclean will remove the package.
> And this is ok, because it means it is actually not needed by any other
> package (and also you do not want it since otherwise you would have
> entered it in your world file...). However, it might happen that in your
> current system some package has been compiled against a library of
> this package - in this case you have to recompile that package
> (That's why the revdep-rebuild is necessary).
>

As it seems --depclean also suggest to remove packages that do not have
any dependencies themselves.

I took a quick look at xdm. "equery d xdm" reveals that xdm has no
dependencies itself (at least in my USE environment) but is needed (or
desired) by xorg. Still --depclean suggests to remove that package even
though it's in my world file.

>> If there is no newer "version" (meaning instance, regardless of version
>> number), there is no problem. Then emerge -C will succeed.
>
> This has nothing to do with a newer version.
>

Please elaborate

>>> Anyhow, if I understand you correctly the second step is that you're
>>> filtering the output of emerge -pe world to find occurrences of
>>> [ebuild...] but not [ebuild R...] to see whether there are packages that
>>> haven't been detected by an emerge --newuse --whatever ?
>> Indeed. There sometimes are, unfortunately.
>
> It remains mysterious why one should want to find such packages.

In case some packages are not being updated and security issues arise at
some point, you may wind up with a vulnerable system without even
knowing about it. I find it very much desirable to find such packages.

Regards,

Tom

Martin Vaeth · External Since: Jul 23, 2005 Posts: 44

Arthur Hagen <art DeleteThis @broomstick.com> schrieb:
> Martin Vaeth <vaeth DeleteThis @mathematik.uni-wuerzburg.de> wrote:
>
> Packages that don't show up with emerge -puDN world, but which shows an U,
> i.e. there is a new version, with emerge -pe world.

....shows an *U* and is pulled in by *emerge -pe world* but does not
show up with emerge -puDN world? If such a package really occurs,
this is a portage bug. Which portage version are you using?

> We're not talking about recompiling everything, but upgrading the packages
> for which there ARE a new version, whether or not --update --deep --newuse
> world can find them or not.

If there is no portage bug, the only packages for which there are new
versions which are not found by -puDN world should be the following:

I. Packages for which a *particular* version is required as a dependency
for some package in world (or a dependency thereof). It is a bug in
the portage tree if these versions are not slotted (this happens
sometimes, but new portage versions will complain, and older
portage version will run these upgrade/downgrade loops).

II. Packages which are installed but actually do not occur anymore in
world or as a dependency of world.

However, both types of packages will also not show up with emerge -pe world.
Packages of type II are the candidates for deletion with --depclean.

> The thing is that EVEN IF IT HAS A NEW VERSION/REVISION NUMBER, -uDN world
> doesn't always mark the packages for update. Need an example? I just
> updated app-arch/cabextract on several machines, from 1.1 to 1.2.

The only package which requires cabextract is corefonts, and corefonts
does not require a particular version, so from the portage tree
everything is completely ok with cabextract. If it really shows up
with -pe world but not with -uDN world on the same machine this is
a bug in portage and should be reported. (Of course, *the same machine*
is important. E.g. on amd64 cabextract-1.2 is still masked.)

> As for depclean (or really emerge -C) not removing binaries when the MD5
> doesn't match, that's just BAD.

I agree. Actually this can even happen for a simple package *upgrade*
(if a file is not part of the upgraded version but the checksum does
not match; in this way e.g. the *.la files are left on many systems
and cause trouble, because they are modified when you remove an old gcc
version). I would really prefer that portage always removes all old
files, regardless of time, checksum, or even CONFIG_PROTECT. However,
this would require a change in portage, because portage would have to
remember during an upgrade which files just had beed installed to avoid
removal of these files (currently it need not care about, because it
relies for the new installed files that they have a different date).
Of course this leads to problems if two packages provide the same file,
but this is a QA violation anyway.
However, whenever this issue comes up, somebody argues that he *wants*
the old files, in particular since the modified files are usually
config-files.

> A -j option (Nike option) for forcing it
> to uninstall all files no matter what the md5 or timestamp is would be a
> good idea, but to partially uninstall and then pretend it's uninstalled when
> leaving behind *binaries*

I completely agree. If you suggest this somewhere, I would support you,
but I am afraid that any bug in this direction will be immediately marked
invalid, because the portage developers apparently are very prejudiced
against this - portage behaves differently now for years...

I resignated and run findcruft from time to time to check for files
which do not appear in any */CONTENTS

However, to be honest: as long as the binaries are not SUID/SGID,
they are not really a security risk. Their negative effect is only
that they waste disk space and pollute the system (so that e.g. you
cannot be sure without findcruft whether a certain file [e.g. a config file]
is really honoured by your system).

> (Yes, emerge spits out a warning among all the hundreds or thousands of
> lines, but no-one in their right minds ever reads every single line of
> output from emerge, so in reality it goes unnoticed.)

Configure the PORTAGE_ELOG variables in /etc/make.conf...

Arthur Hagen · External Since: May 30, 2004 Posts: 45

On Fri, 2007-06-15 at 09:07 +0000, Martin Vaeth wrote:

> However, to be honest: as long as the binaries are not SUID/SGID,
> they are not really a security risk. Their negative effect is only
> that they waste disk space and pollute the system (so that e.g. you
> cannot be sure without findcruft whether a certain file [e.g. a config file]
> is really honoured by your system).

No, they can still be security risks. Imagine a binary, "foo" which
resides in /usr/sbin, and which gets left behind after an unmerge. The
admin installs a competing package, which creates an /sbin/foo file
instead. Since the two behave identically, the admin doesn't realise
that /usr/sbin/foo is still being used because it precedes /sbin/foo in
the PATH. Then years down the road, someone discovers a security hole
in the old /usr/sbin/foo, where it populates a /tmp/tempfile.$$ with
variables and execs it. The hacker creates a few thousand temp files,
and waits until the superuser calls the binary. *BAM*

> > (Yes, emerge spits out a warning among all the hundreds or thousands of
> > lines, but no-one in their right minds ever reads every single line of
> > output from emerge, so in reality it goes unnoticed.)
>
> Configure the PORTAGE_ELOG variables in /etc/make.conf...

You still have to read it, though...

Regards,
--
*Art

Martin Vaeth · External Since: Jul 23, 2005 Posts: 44

tHOM! <thom.DeleteThis@the-altered-states.de> wrote:
>
> So that means whenever someone or something would change any file of a
> package (deliberately or by accident), it wouldn't go unnoticed since
> the gpg signature protects the Manifest which in turn protects the
> package's files by providing portage with the correct checksums during
> operation (whenever needed) ?

That's what I thought. However, now I get confused, because
when I just looked through some recent Manifest files, I cannot
find any gpg signature in them. How comes that you do?

> check back with equery to find
> out if there are any dependencies attached to the package in question.

equery is not reliable in finding dependencies, because it does not
take USE flags into account (and perhaps not even eclasses).
Usually, I never use --depclean at all: I compare the output of an
emerge -De world with the installed packages and remove the
difference (the command "world test" with the world script from
http://www.mathematik.uni-wuerzburg.de/~vaeth/gentoo/index.html
outputs this difference)

> Precisely - and because the upstream maintainers sometimes miss these
> things, I usually want to recompile everything in world to minimize the
> chance of bad things happening.

You will soon see that this is not possible in practice.
Actually, you will have to recompile world n times if you have n packges
to be sure nothing wrong was used, but also this won't save you:
There might be an orphant .la file which caused something to link against
an obsolete library, or similar things.
Somebody gave even an example (IIRC it was in some alsa stuff)
where the developers had used #include <....> although they had meant
#include "..." so that always the wrong header files were taken.
Since you can never be sure about such mistakes and recompiling
packages unnecessarily does not decrease the chance for such mistakes
significantly, the "normal" practice of just compiling the changed
packages and whatever revdep-rebuild says is most reasonable.

tHOM! · External Since: Jun 11, 2007 Posts: 6

Martin Vaeth wrote:
> tHOM! <thom RemoveThis @the-altered-states.de> wrote:
>> So that means whenever someone or something would change any file of a
>> package (deliberately or by accident), it wouldn't go unnoticed since
>> the gpg signature protects the Manifest which in turn protects the
>> package's files by providing portage with the correct checksums during
>> operation (whenever needed) ?
>
> That's what I thought. However, now I get confused, because
> when I just looked through some recent Manifest files, I cannot
> find any gpg signature in them. How comes that you do?
>

check app-editors/nano <- 25th of May or app-editors/vim <-31st of May
I guess that still qualifies for recent.

>> check back with equery to find
>> out if there are any dependencies attached to the package in question.
>
> equery is not reliable in finding dependencies, because it does not
> take USE flags into account (and perhaps not even eclasses).
> Usually, I never use --depclean at all: I compare the output of an
> emerge -De world with the installed packages and remove the
> difference (the command "world test" with the world script from
> http://www.mathematik.uni-wuerzburg.de/~vaeth/gentoo/index.html
> outputs this difference)
>
>> Precisely - and because the upstream maintainers sometimes miss these
>> things, I usually want to recompile everything in world to minimize the
>> chance of bad things happening.
>
> You will soon see that this is not possible in practice.
> Actually, you will have to recompile world n times if you have n packges
> to be sure nothing wrong was used, but also this won't save you:
> There might be an orphant .la file which caused something to link against
> an obsolete library, or similar things.
> Somebody gave even an example (IIRC it was in some alsa stuff)
> where the developers had used #include <....> although they had meant
> #include "..." so that always the wrong header files were taken.
> Since you can never be sure about such mistakes and recompiling
> packages unnecessarily does not decrease the chance for such mistakes
> significantly, the "normal" practice of just compiling the changed
> packages and whatever revdep-rebuild says is most reasonable.

You're right of course but I figured that something like linking against
and old library would not go unnoticed since it should break things
horribly. However I did not think of the case in which one would use
"<...>" instead of "..." and be so unlucky that the code still compiles
using the wrong .h or something. This could happen of course.

I guess you saved me lot of compile time from today Smile

Regards,

Tom

Martin Vaeth · External Since: Jul 23, 2005 Posts: 44

tHOM! <thom.DeleteThis@the-altered-states.de> wrote:
>
> check app-editors/nano <- 25th of May or app-editors/vim <-31st of May
> I guess that still qualifies for recent.

Yes, but many which I checked now are not signed and emerge fine.
So you cannot really rely that they have not been (intentionally)
corrupted by big brother.

> You're right of course but I figured that something like linking against
> and old library would not go unnoticed

Of course this happens at most in some exceptional cases -
but this is why in the normal cases the "usual" update is sufficient.
You might also want to look at
http://forums.gentoo.org/viewtopic-t-494409.html

tHOM! · External Since: Jun 11, 2007 Posts: 6

Martin Vaeth wrote:
>
> Yes, but many which I checked now are not signed and emerge fine.
> So you cannot really rely that they have not been (intentionally)
> corrupted by big brother.
>

I remember reading somewhere in make.conf that heavy gpg signature
support is coming soon but to be honest that was like over a year ago.
Today I tried to enable gpg in FEATURES and set PORTAGE_GPG_DIR but the
result was an error in emerge while doing a --sync. I left it at that
for the moment.

> Of course this happens at most in some exceptional cases -
> but this is why in the normal cases the "usual" update is sufficient.
> You might also want to look at
> http://forums.gentoo.org/viewtopic-t-494409.html

Thanks for the link

Regards,

Tom