On Mon, Jun 22, 2020 at 02:03:10PM +0200, Michael Meskes wrote: > > I already updated the title of the mass-merged bug to > > "bsdmainutils must depend on bsdextrautils". > > > > This is anyway mandatory for not breaking upgrades from buster. > > Would you care to elaborate? I didn't find anything that mandates a dependency > over a recommendation.
It is common practice to have dependencies for one Debian release, to ensure noone loses during an upgrade what was moved elsewhere. > Yes, it does break build dependencies but imo they should > be changed anyway. Build breakage out of the void is not nice, usually maintainers inform reverse build dependencies them before making such a breaking change. The same is true for runtime dependencies, where breakage can be much more user-visible. Worst are breakages it might cause for users upgrading from buster to bullseye. The majority of users are using the default of treating Recommends as dependencies, for them it doesn't make any difference whether Recommends or Depends is used. Not installing Recommends is supported, and desirable in many embedded/server/container scenarios. The documented way to upgrade to a new stable release is basically apt-get upgrade apt-get dist-upgrade Without a dependency the first step might upgrade bsdmainutils, but will never install bsdextrautils. I do not know for what tools software like salt or libguestfs in buster depends on bsdmainutils, and I definitely do not want our users to learn the hard way during an upgrade. Installing bsdmainutils from unstable in buster breaks commands like man ncal | cat I would not be surprised if there is somewhere in Debian some package that would do something like that for whatever good or bad reason in a postinst or prerm. > Michael cu Adrian BTW: The naming of the packages is confusing. "extra" sounds like the more obscure utils, enhanching the more commonly used "main" tools. Looking at the tools shipped, the opposite seems to be true. One could make the point that bsdmainutils should be a (transitional?) metapackage depending on all the tools it previously provided.
