On Tue, 2024-09-24 at 17:16 +0200, Thorsten Glaser wrote: > On Tue, 24 Sep 2024, Ben Hutchings wrote: > > > I suppose I can make this work again for bookworm, but I won't do so > > for unstable. > > Then, perhaps issue a visible warning so that people can change > their scripts?
Yes.
> > This was not an intended feature. When specifiing a diectory as the
> > target you are supposed to ensure that it already exists under
> > ${DESTDIR}. It seems that this just happened to work when the target
> > name ended in a slash.
>
> Hmmh, but this is used in so many other places, e.g. dh_install
> does that, and many of the other scripts also don’t place filenames
> after directories, they are just lucky that the directories exist
> then.
>
> But, wait, copy_exec *DOES* create missing directories, so this
> *does* look like intended behaviour to me…
There used to be a comment explaining this:
# $1 is the source path (e.g. /usr/bin/time)# $2 is the relative destination
(e.g. /usr or /usr/time)
#
# The destination is interpreted in the same way "cp" would, meaning
# (assuming /bin is a directory):
#
# "copy_exec /usr/bin/time /bin" -> /bin/time
# "copy_exec /usr/bin/time /bin/mytime" -> /bin/mytime
#
# If $2 is left out, the same destination path as for the source arg will
# be used and directories will be created as needed, so:
#
# "copy_exec /usr/bin/time" -> /usr/bin/time
but that was lost somewhere along the way.
> > The changes in the last point release to avoid duplicating files
> > accessed via directory symlinks broke that because realpath strips the
> > trailing slash.
>
> Hmh.
>
> IMHO we have two ways we can go from here (also towards sid).
>
> One, repair this. If there is a trailing slash, it’s supposed
> to be placed into that directory, then create that if missing.
> That is, make bullseye’s behaviour the intended one.
Now that I've tested, I see that this has worked since at least squeeze
(that's the oldest image I have available). So I'm now leaning towards
restoring and documenting it.
> Two, say people are expected to create the directories first.
> But in that case, copy_exec also must not create any missing
> directories any more *at all*,
No, it was documented to do that for the case where no target argument
was given, and changing that would likely cause widespread breakage.
> and additionally, if the target
> ends in a slash in the argv (i.e. before realpathisation), it
> still must be interpreted as the name of a directory (or symlink
> to a directory), so that copying to '/usr/libexec/' will either
> work (if pre-created) or fail (if not pre-created).
I agree that we mustn't create the target filename as a regular file if
it originally ended with a slash.
Ben.
> These two
> are needed for consistency and to have a sensitive failure mode
> for users’ scripts, as opposed to create /usr/libexec as file.
--
Ben Hutchings
Knowledge is power. France is bacon.
signature.asc
Description: This is a digitally signed message part
