Jari Aalto <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:
>> To be frank, I don't think you're going to have a lot of luck.
>> Basically, you're trying to move bash into the same category as awk,
>> where it's not explicitly essential and can be handled by something
>> akin to alternatives, but given that this will require modifying all
>> packages that use bash explicitly and there's little incentive for
>> maintainers to do this unless it's made RC (and I have a hard time
>> imagining that would happen), I don't think the transition is likely to
>> happen. It's a lot of work, and the amount of gain doesn't seem to
>> warrant it.
> I must have explained poorly then.
> - There is no need to make *any* changes to packages
You proposed a wording change to Policy making adding a dependency to bash
mandatory for packages that use bash. That requires making changes to
*lots* of packages.
Maybe you meant to propose a change that just made it *optional* to add a
dependency on bash?
> The problem is that policy gives a leverage to the maintainers to shrug
> their shoulders to anything that touches something belonging Essential:
> "It's there so I don't care". And when the Policy text alleviates that
> "packages provided by Essestial need not be mentioned", that the final
> straw.
Right, that's much of the point of Essential. You've seen the Policy
footnote, I presume?
Essential is defined as the minimal set of functionality that must be
available and usable on the system even when packages are in an
unconfigured (but unpacked) state. This is needed to avoid
unresolvable dependency loops on upgrade. If packages add unnecessary
dependencies on packages in this set, the chances that there will be
an unresolvable dependency loop caused by forcing these Essential
packages to be configured first before they need to be is greatly
increased. It also increases the chances that frontends will be unable
to calculate an upgrade path, even if one exists.
Also, it's pretty unlikely that functionality from Essential shall
ever be removed (which is one reason why care must be taken before
adding to the Essential packages set), but packages have been removed
from the Essential set when the functionality moved to a different
package. So depending on these packages just in case they stop being
essential does way more harm than good.
That's a pretty strong argument against doing what you're proposing in
general. I think a lot of justification is required to change this.
> Now, I'm asking for thinking it another way around:
> - It's all good to announce only dpendencies that are not in Essential
> - BUT, it should be encouraged to list all dependencies even if
> in essential.
I'm opposed to doing this for the reasons spelled out in Policy. I think
it adds a bunch of additional work and causes problems for dependency
resolution with no significant benefit.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
