Re: Proposed new POSIX sh policy, version two
Russ Allbery <rra@debian.org> writes:
> Jari Aalto <jari.aalto@cante.net> writes:
> > Russ Allbery <rra@debian.org> 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?
Correct.
> > 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.
And making bash essential on the gounds that "must be available" is
not a good idea. I guess this is a chicken and egg situation
I'd rather make it read:
> Essential represents the minimal set of functionality that are
> available on a 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.
I think the policy should be implementation agnostic. What is referred
here is tying it to the dependency resolution algorithm that is true at a
particular time. I'm quite sure that the install case can be
made to skip any package that is mentioned in the "Depends: " that is
in the the list of Essential. Like:
Depends: bash, .....
=> Algorithm:
Hm, bash is in the list of essential-packages.lst, drop it and
resolve only other packages mentioned in Depends:
Listing the packages in the Depends should not necessarily cause any
more work to the tools. I'm sure patches can me made to correct the
tools.
Jari
Reply to: