1,574
edits
Changes
From SME Server
Jump to navigationJump to search→DEALING WITH PACKAGE DEPENDENCIES.
|}
|}
The verification phase taking place before release should pick up hard dependencies which could break an update. To the best of my understanding, the 'Verified Package Versions' tab in Rnotes will track hard dependencies - it does what Ian used to do normally and try to build a bug and package dependency graph <span style="color: red;">To be confirmed</span>.
The verification phase taking place before release should pick up hard dependencies which could break an update. To the best of my understanding, the 'Verified Package Versions' tab in Rnotes will track hard dependencies - it does what Ian Wells used to do normally and try to build a bug and package dependency graph <span style="color: red;">To be confirmed</span>.
What needs to be checked manually is where a package fixes three bugs and one was not verified, the so-called soft dependencies. It means that only an older version of that package can be released. Also it can affect other packages if one of the fixes involved multiple packages. <span style="color: red;">To be confirmed</span>
What needs to be checked manually is where a package fixes three bugs and one was not verified, the so-called soft dependencies. It means that only an older version of that package can be released. Also it can affect other packages if one of the fixes involved multiple packages. <span style="color: red;">To be confirmed</span>
:a) Hard dependencies are those from the spec file, eg: requires: e-smith-lib >= 2.0.0-2
:a) Hard dependencies are those from the spec file, eg: requires: e-smith-lib >= 2.0.0-2
Developers put these when it is necessary to enforce dependencies between packages.
Developers put these in when it is necessary to enforce dependencies between packages.
:b) Soft dependencies relates to .... <span style="color: red;">needs a definition</span>
As an illustration of soft deps, consider the following scenario, actual bug numbers etc are made up for this example:
As an illustration of soft deps, consider the following scenario, actual bug numbers etc are made up for this example:
*e-smith-apache 2.0.0-7 cannot be released as part of the fix for Bug 4633 is in e-smith-pop3 2.0.0-1 which is not being released.
*e-smith-apache 2.0.0-7 cannot be released as part of the fix for Bug 4633 is in e-smith-pop3 2.0.0-1 which is not being released.
If you carefully check the code changes it may be possible to release e-smith-pop3 & e-smith-apache in the example above, but safest not to.
If you carefully check the code changes it may be possible to release e-smith-pop3 and e-smith-apache in the example above, but safest not to do so.
Note: Shad's automated script doesn't do any blocking of packages. It just tries to sort out where packages should belong based on where things exist when it starts running.
Note: Shad's automated script doesn't do any blocking of packages. It just tries to sort out where packages should belong based on where things exist when it starts running.
