Philip Kaludercic <philipk@posteo.net> writes:

>> Forget it, it is working properly, just forget you had modified
>> package--dependencies as well.
>> Sorry for the noise.
>
> It was either that or a new function had to be added, not sure which
> approach is worse.  The current implementation seems to have been
> hastily added by Lars last year, and it is a bit regrettable in
> retrospect.  It would be possible to modify my change, and have the
> function always return package-desc objects, since the function is only
> used in one other spot in another part of the file.  While there might
> be others (packages or individuals) that depend on the function behaving
> the way it does, but on the other hand, convention designates it as
> being an "internal" function.

The actual version is something like 4 or 5 lines long, so external
packages can inline this version under another name if really needed,
but your version is covering the both so it's ok I think.
OTOH The problem with package.el is inconsistency within its functions,
sometimes you have to use a pkg-desc as arg, sometimes not, sometimes
functions return a list of symbols sometimes a list of pkg-desc, what is
a package name, a string or a symbol? What is a pkg-desc exactly,
sometimes it is the cdr in other places the cadr is used...
Also built-in packages don't have the same format unless they are distributed
in Elpa etc...

>> Some packages seems to require a specific version of a package for their
>> dependency e.g. seq, by excluding it the package may not work correctly,
>> this is my understanding but I may be wrong. Also perhaps the package
>> e.g. seq is selected later when computing dependencies but maybe user
>> wants to select a particular version manually in the first place?
>
> The current algorithm should pick the first package in the package alist
> that satisfies the necessary dependencies.  Perhaps that should be
> re-thought or the selection should be more clever, e.g. if the user
> explicitly specifies a dependency with a version, then it should be
> preferred to whatever other dependency might be determined, at the
> possible expense of triggering runtime bugs.

I think it is hard to cover all cases, but after all it is more a
developer tool for debugging a particular package than a end user tool
to run packages, so perhaps the developer can give directives about
dependencies to use when needed.

Another thing, you use actually 

    (expand-file-name invocation-name invocation-directory)

I suggest you use the truename of this instead as emacs can be symlinked
in some installations.  It should work with the symlink name, but it is
clearer which emacs version is used.

Now your function is working fine and nearly finish, did you think how
you are going to distribute it? It seems you are going to merge it in
master, but what about providing it as well as a Elpa package so that
users of old emacs (at some point of course, say emacs-27) can use it to
report bugs?

Thanks.

-- 
Thierry