:: Re: [devuan-dev] Notes - Devuan mee…
Page principale
Supprimer ce message
Répondre à ce message
Auteur: Jaromil
Date:  
À: devuan developers internal list
Sujet: Re: [devuan-dev] Notes - Devuan meet Jul. 24, 2019
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

> Just adding some further facts of, e.g. things like ansible will now think a
> Devuan Beowulf installation is Debian Stretch:
>
>       "ansible_distribution": "Debian",
>       "ansible_distribution_file_variety": "Debian",

>
>
> As opposed to:
>
>       "ansible_distribution": "Devuan",
>       "ansible_distribution_file_variety": "Debian",

>
> That's the most obvious one I just thought of, but this effectively means
> that anything that was already relying on being able to treat Debian and
> Devuan apart, often via lsb_release -i, will confuse the two and maybe try
> to do systemd stuff (and fail at it).


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! ;^)

> 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

ciao