On ds., ag. 10 2019, jaromil@??? wrote:

> On Sat, 10 Aug 2019, Evilham wrote:
>
>> > Resolutions: Consensus to change that do "debian" in order
>> > to
>> > not fork
>> > too many packages included grub2 now constituting the
>> > problem
>> > Centurion_Dan will commit the change to the base-files
>> > package
>>
>>
>> Is this final?
>
> yes, we operated the change


Alrighty, just make sure it is very clearly and prominently stated
in the release notes.


> there are ways to check if Devuan for those who need to
>
> in any case: in what way this is impacting anything?
>
> what is relying on being able to treat Debian and Devuan apart?
>
> it is in our impression the contrary, that most tools need to
> treat
> Debian and Devuan alike to work.
>
> I also suggest that, since the decision was taken, anyone
> willing to
> revert this should take responsibility of maintaining a fork of
> all
> packages broken by setting Debian and Devuan apart. My
> estimation of
> this effort is "impossible", but please! surprise me! ;^)


Nope. As you well know, in Devuan I'll only deal with things
related to the mirror network right now, thank you.


>> I'm also unsure how things like unattended-upgrades will react,
>> that
>> package relies on lsb_release saying that the OS is Devuan, in
>> order
>> to put the proper config file in-place and not one for
>> Debian's,
>> rendering the package useless without manual config, other
>> things
>> may not be as harmless.
>
> can you be more specific with an example of package that would
> break
> in such a situation? we fork packages anyway. If necessary,
> would be
> still easier to fork unattended-upgrades for whatever reason.
>
>> The benefits may be deemed greater than this class of issues,
>> I'm just
>> mentioning these two, and there could be a bunch more :-)
>
> mmm, sounds like sort of falling into the category of benign FUD
> to me


Yes, it can be FUD and I can be wrong and biased.
That's because these were literally the first two things that came
to mind in a thought exercise of 5 minutes, and they both had the
potential to be problematic after checking a bit; I just confirmed
they are problematic in practise.

The case of Ansible: it relies ansible_distribution and
ansible_distribution_release being properly defined (and they come
from lsb_release).
This is used, e.g. to provision servers and machines and, amongst
other things, to decide which repositories are to be enabled in
certain machines.
If the system says it's Debian, it's not crazy to set it up with
the repositories in the closest **Debian** mirror; that's a fun
state for Devuan to find itself in.
Other provisioning tools do similar things by default (make
decisions based on "constants/facts" provided by the system).

The case of unattended-upgrades: indeed as predicted it now
installs Debian's /etc/apt/apt.conf.d/50unattended-upgrades, which
means that it won't match Devuan's repositories.
So, the patch that we landed upstream months ago is effectively
being ignored. If the package isn't forked, people's expectation
that unattended-upgrades will install security upgrades by default
will be broken.

Maybe I was super lucky and these are the only two issues, maybe
not.

In the end everything can be worked around by good sysadmins
though, that's why it's important that this is listed in the
release notes both clearly and prominently.
--
Evilham