[pkg-discuss] Explicit dependencies causing pkglint errors
Seth Goldberg
I'm trying to figure out how to specify an explicit dependency from a
package in the install incorporation to a package in the osnet incorporation.
When I add an explicit depend at a specific version, pkglint outputs an error:
ERROR pkglint.manifest005.2 duplicate depend actions in pkg:/install/insta...@0.5.11,5.11-0.175.1.0.0.13.1820 system/library/boot-management
So the questions are: how can I realy see ALL of the packages for which
pkglint detected conflicting dependencies, and how can I specify a minimum
version for a package (boot-management in this case) when other packages in
the incorporation have had a different version added via automatic
dependency generation (pkgdepend)?
--S
_______________________________________________
pkg-discuss mailing list
pkg-d...@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
Brock Pytlik
Can you point us to the manifest that's producing this error? I think
what this error message is saying is that you have two require
dependencies on system/library/boot-management. Given that installadm
doesn't have an incorporate dependencies in it, I'm confused as to where
your reference to "the incorporation" came from. What version are you
trying to set as the minimum version, and what version is pkgdepend using?
Brock
Niall Power
On 21/03/2012 09:21, Brock Pytlik wrote:
> On 03/19/12 23:50, Seth Goldberg wrote:
>> Hi,
>>
>> I'm trying to figure out how to specify an explicit dependency from
>> a package in the install incorporation to a package in the osnet
>> incorporation.
>> When I add an explicit depend at a specific version, pkglint outputs
>> an error:
>>
>> ERROR pkglint.manifest005.2 duplicate depend actions in
>> pkg:/install/insta...@0.5.11,5.11-0.175.1.0.0.13.1820
>> system/library/boot-management
>>
>> So the questions are: how can I realy see ALL of the packages for
>> which pkglint detected conflicting dependencies, and how can I
>> specify a minimum version for a package (boot-management in this
>> case) when other packages in the incorporation have had a different
>> version added via automatic dependency generation (pkgdepend)?
>>
>> --S
>> _______________________________________________
>> pkg-discuss mailing list
>> pkg-d...@opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
> Hi Seth,
> Can you point us to the manifest that's producing this error?
Repo:
ssh://ni...@hg.opensolaris.org/hg/caiman/slim_uefi
File:
usr/src/pkg/manifests/install-installadm.mf
URL:
http://src.opensolaris.org/source/xref/caiman/slim_uefi/usr/src/pkg/manifests/install-installadm.mf
I haven't pushed the change to the manifest. The addition I am
attepmting is as follows:
depend type=require \
fmri=pkg:/system/library/boot-ma...@0.5.11,5.11-0.175.1.0.0.13
> I think what this error message is saying is that you have two require
> dependencies on system/library/boot-management.
The installadm package has a basic API and runtime dependency on
system/library/boot-management.
However, to ensure the correct functionality and feature support is
present, the boot-management version must be build 13 or greater.
So if we do a build without the manual dependency specified, it auto
generates a dependency on
system/library/boot-ma...@0.5.11,5.11-0.175.1.0.0.11 - the version
it detected on the build machine.
Then pkglint finds 2 dependencies on boot-management and bails out.
For the sake of comparison I tried the same process against
ssh://ni...@hg.opensolaris.org/hg/caiman/slim_uefi whose installadm has
no dependencies on boot-management (the dependency is introduced in the
slim_uefi repo because installadm imports bootmgmt) and
there appeared to be no pktlint or pkg issues
Thanks,
Niall
> Given that installadm doesn't have an incorporate dependencies in it,
> I'm confused as to where your reference to "the incorporation" came
> from. What version are you trying to set as the minimum version, and
> what version is pkgdepend using?
>
> Brock
> _______________________________________________
> pkg-discuss mailing list
> pkg-d...@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
Brock Pytlik
1) Upgrade your build machine to something running build 13, from an ON
build you did yourself for example
or 2) Disable automatic dependency for the action(s) which find a
dependency on system/library/boot-ma...@0.5.11,5.11-0.175.1.0.0.11
or 3) Mark either the manually added or generated dependency on
system/library/boot-management as linted so pkglint ignores the
duplicate dependencies.
Hth,
Brock
Niall Power
1 is not really ideal for us because we want to explicitly want to
prevent a mix and match scenario where someone would try to use
installad from build 13+ on a build 12 or earlier system.
2: Can we disable a specific automatic dependency here or is it applied
to the entire package? If it's an entire/global action then it would
have some undesirable side effects.
How do I specify this?
3: I tried this (by adding the property pkg.linted=true to the depend
line above. It built and linted correctly however it resulted in 2
dependencies listed against boot-management
system/library/boot-ma...@0.5.11,5.11-0.175.1.0.0.11.0
system/library/boot-ma...@0.5.11,5.11-0.175.1.0.0.13
Will this double dependency be a problem?
Thanks,
Niall
Brock Pytlik
The pkgdepend man page describes what you need to do in detail. At a
high level, you'll tag the action(s) which produce the dependency on
system/library/boot-ma...@0.5.11,5.11-0.175.1.0.0.11 (in your case,
at minimum the file action that delivers installadm since it imports
bootmgmt) so you'd do something like 'pkg.depend.bypass-generate=bootmgmt'.
>
> 3: I tried this (by adding the property pkg.linted=true to the depend
> line above. It built and linted correctly however it resulted in 2
> dependencies listed against boot-management
> system/library/boot-ma...@0.5.11,5.11-0.175.1.0.0.11.0
> system/library/boot-ma...@0.5.11,5.11-0.175.1.0.0.13
>
> Will this double dependency be a problem?
I am not aware of any problems this causes, but you aren't in a well
tested space at this point I think. Perhaps someone else will feel
confident to state that it is not (or is) a problem.
Brock
[snip]
Tim Foster
> The pkgdepend man page describes what you need to do in detail. At a
> high level, you'll tag the action(s) which produce the dependency on
> system/library/boot-ma...@0.5.11,5.11-0.175.1.0.0.11 (in your case,
> at minimum the file action that delivers installadm since it imports
> bootmgmt) so you'd do something like 'pkg.depend.bypass-generate=bootmgmt'.
That's the correct thing to do here. Be sure to add a comment saying why
you're bypassing dependency generation on this file, and add a comment
warning developers to check that the manual dependency always exists,
and is kept up to date lest the file you're actually depending on within
that package gets refactored into another package without the manual
dependency being updated.
>> 3: I tried this (by adding the property pkg.linted=true to the depend
>> line above. It built and linted correctly however it resulted in 2
>> dependencies listed against boot-management
>> system/library/boot-ma...@0.5.11,5.11-0.175.1.0.0.11.0
>> system/library/boot-ma...@0.5.11,5.11-0.175.1.0.0.13
>>
>> Will this double dependency be a problem?
> I am not aware of any problems this causes, but you aren't in a well
> tested space at this point I think. Perhaps someone else will feel
> confident to state that it is not (or is) a problem.
I'm not sure what happens here either. I would also say that
"pkg.linted=true" is too big a hammer, since that will disable all
linting for that particular action. Better would be:
pkg.linted.pkglint.action005.1=true
which would cause just this lint error to be ignored. Adding the bypass
is almost certainly the right thing to do, rather than using pkg.linted
tags. The syntax for bypass tags is documented in pkgdepend(1)
cheers,
tim
Niall Power
On 21/03/2012 12:19, Tim Foster wrote:
> On 03/21/12 02:06 PM, Brock Pytlik wrote:
>> The pkgdepend man page describes what you need to do in detail. At a
>> high level, you'll tag the action(s) which produce the dependency on
>> system/library/boot-ma...@0.5.11,5.11-0.175.1.0.0.11 (in your case,
>> at minimum the file action that delivers installadm since it imports
>> bootmgmt) so you'd do something like
>> 'pkg.depend.bypass-generate=bootmgmt'.
>
> That's the correct thing to do here. Be sure to add a comment saying
> why you're bypassing dependency generation on this file, and add a
> comment warning developers to check that the manual dependency always
> exists, and is kept up to date lest the file you're actually depending
> on within that package gets refactored into another package without
> the manual dependency being updated.
>
I'll try that out. So I am guessing that it would look something like
the following?
file \
path=usr/lib/python2.6/vendor-packages/osol_install/auto_install/set_service.py
\
group=sys pkg.depend.bypass-generate=system/library/boot-management
I assume both .py and .pyc files need to be correspondingly tagged also.
Thanks,
Niall
Brock Pytlik
> Hi Tim & Brock,
>
>
> On 21/03/2012 12:19, Tim Foster wrote:
>> On 03/21/12 02:06 PM, Brock Pytlik wrote:
>>> The pkgdepend man page describes what you need to do in detail. At a
>>> high level, you'll tag the action(s) which produce the dependency on
>>> system/library/boot-ma...@0.5.11,5.11-0.175.1.0.0.11 (in your
>>> case,
>>> at minimum the file action that delivers installadm since it imports
>>> bootmgmt) so you'd do something like
>>> 'pkg.depend.bypass-generate=bootmgmt'.
>>
>> That's the correct thing to do here. Be sure to add a comment saying
>> why you're bypassing dependency generation on this file, and add a
>> comment warning developers to check that the manual dependency always
>> exists, and is kept up to date lest the file you're actually
>> depending on within that package gets refactored into another package
>> without the manual dependency being updated.
>>
> I'll try that out. So I am guessing that it would look something like
> the following?
>
> file \
>
> path=usr/lib/python2.6/vendor-packages/osol_install/auto_install/set_service.py
> \
> group=sys pkg.depend.bypass-generate=system/library/boot-management
>
> I assume both .py and .pyc files need to be correspondingly tagged also.
>
Remember that the value of bypass-generate is the file name/path, not
the package name.
Brock
Niall Power
Ah ok. Thanks for the clarification. So that suggests that all other
automatic package dependency generation will be bypassed also?
Is that correct? Is there no way to restrict it to
system/library/boot-management ?
Thanks,
Niall
Brock Pytlik
I don't understand. You restrict it based on files. So, in this case, I
imagine you'd set the value of bypass-generate to be something like
"bootmgmt" on the action delivering installadm. Now, if another action
also delivers a file which causes a dependency on
system/library/boot-management to be inferred, then you'll likely need
to bypass that one as well.
Brock
Niall Power
My bad. I mis-interepreted the man page description and missed the
example. Will try that and see how I get on.
Thanks!
Niall
Shawn Walker
> On 03/20/12 17:59, Niall Power wrote:
...
>> 3: I tried this (by adding the property pkg.linted=true to the depend
>> line above. It built and linted correctly however it resulted in 2
>> dependencies listed against boot-management
>> system/library/boot-ma...@0.5.11,5.11-0.175.1.0.0.11.0
>> system/library/boot-ma...@0.5.11,5.11-0.175.1.0.0.13
>>
>> Will this double dependency be a problem?
> I am not aware of any problems this causes, but you aren't in a well
> tested space at this point I think. Perhaps someone else will feel
> confident to state that it is not (or is) a problem.
Since one version is simply greater than the other, it will work just
fine. But it's also a bit silly to have this.
-Shawn
Shawn Walker
I would go ahead and tag the .pyc files; long-term, we'll need to
consider analyzing .pyc files using the parse tree as python programs
are not required to deliver the .py files.
-Shawn
Niall Power
> On 03/20/12 18:06, Brock Pytlik wrote:
>> On 03/20/12 17:59, Niall Power wrote:
> ...
>>> 3: I tried this (by adding the property pkg.linted=true to the depend
>>> line above. It built and linted correctly however it resulted in 2
>>> dependencies listed against boot-management
>>> system/library/boot-ma...@0.5.11,5.11-0.175.1.0.0.11.0
>>> system/library/boot-ma...@0.5.11,5.11-0.175.1.0.0.13
>>>
>>> Will this double dependency be a problem?
>> I am not aware of any problems this causes, but you aren't in a well
>> tested space at this point I think. Perhaps someone else will feel
>> confident to state that it is not (or is) a problem.
>
> Since one version is simply greater than the other, it will work just
> fine. But it's also a bit silly to have this.
Thanks Shawn. I was not too mad about that either.
It took a bit more time to weed out all the imports but I got option 2
working using the
bypass-generate action to the offending files:
pkg.depend.bypass-generate=^usr/lib/python2.6/vendor-packages/bootmgmt/.*$
Niall