I misspoke, sorry.  Obviously pkgdepend should add a dependency on
the centralized mediator package for python.  /usr/bin/python
must exist.  I intended to say that pkgdepend should not worry about
which version of python is installed.

I think it's possible and useful for pkgdepend to require that there is
a file at /usr/bin/python.  But I don't think it's useful to require
that pkgdepend knows which one it's going to be.

Why does pkgdepend care which version of python is installed anyway?
What kind of difference does it make to *my* package with a script
if the end user installs 2.4 or 2.6?
Does pkgdepend grovel through my python use statements to make
sure they are also satisfied?

If a user asked me how to write a python script on Solaris, I would tell them 
this:
If your script is fairly simple and expected to run on any contemporary version 
of python,
then use #!/usr/bin/python.  If you tie it to a specific version, you'll need 
to come back
and update it when Solaris changes, and the package you publish today might not
run on newer Solaris releases.  And by the way you'll have to work around a 
pkgdepend
bug...

--chris



On Friday October 28, at    2:02PM, Brock Pytlik wrote:

> On 10/28/11 13:05, Chris Quenelle wrote:
>> pkgdepend should silently skip the /usr/bin/python connection.
>> After all, it doesn't fail for programs which call dlopen or exec right?
> Sorry, I disagree. If you want it to be a warning instead of an error, (ie, 
> it's reported but still exits 0), I could probably live with that.
> 
> Silently skipping #!/usr/bin/python would cause far more issues than it 
> solves I believe since users would not be aware that their scripts are not 
> being analyzed.
> 
> This is a different situation than elf files. #!/usr/bin/python is a hard 
> dependency, it must be there for the program to work. However, since it's 
> unversioned, we can't properly analyze the script, so we report an error to 
> the user. My understanding of how dlopen is supposed to be used is that it's 
> not a hard dependency (otherwise it would just be linked in) so the program 
> is supposed to be able to cope with dlopen failing.
> 
> As for exec (and dlopen as well)... while I would love to be able to be able 
> to solve the halting problem and do what you described, I'm afraid I haven't 
> quite gotten that issue solved yet.
> 
> So in summary, what you seem to be saying is that since pkgdepend will never 
> be able to get all dependencies right, we shouldn't let users know when we 
> know we can't analyze a file we otherwise could simply because of a missing 
> version? If that's you're position, I guess we'll just have to agree to 
> disagree there. Given that a user can bypass dependency generation if adding 
> a version to the #! line is really so onerous, I think what pkgdepend does 
> today is the correct behavior.




> 
>> pkglint should flag scripts that use binaries which are mediated links.
>> And it should mention "mediated links".
> That's an interesting rfe, and probably one worth putting in. Unfortunately, 
> was a recent addition and hasn't been fully integrated with other features 
> (like pkgdepend and pkglint).
> 
> Brock
> 
> 
>> 
>> 
>> 
>> On Friday October 28, at    11:30AM, Danek Duvall wrote:
>> 
>>> /usr/bin/python is not a Committed interface.  A customer can retarget the
>>> link to any version of python they choose -- python 2.0, python 2.7, python
>>> 3.2, unladen swallow, whatever.  Solaris does not control that link.
>>> 
>>> So if you want to ship a script that designates its interpreter as
>>> /usr/bin/python, that's your choice, but the customer can break the script,
>>> and it's your bug, not the customer's issue.
>>> 
>>> If that's the path you want to go, pkgdepend has a mechanism by which you
>>> can tell it to ignore an action when analyzing it for dependencies.  It's
>>> in the manpage.
>>> 
>>> I'm not sure what you'd like to see in terms of a more useful error
>>> message.  It seems pretty clear to me, but I know what the problem is, so
>>> it's pretty straightforward to go solve.
>>> 
>>> Now that you know what the problem is, how could the message have gotten
>>> you there more easily?
>>> 
>>> Danek
>> _______________________________________________
>> pkg-discuss mailing list
>> [email protected]
>> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
> 
> _______________________________________________
> pkg-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to