[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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?

> > 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


Reply to: