Samuel Thibault:
Niels Thykier, le jeu. 15 août 2024 11:22:11 +0200, a ecrit:
I am not seeing signs of nor feel that you are actively looking
I was on holiday...
Ok.
For clarification, that statement was meant as a "I need to know where
we stand", because I did not want you to implicit expect something of me
while I implicitly expected it from you. It was not meant as something
where you needed to justify yourself.
If you had told me, "I am currently on vacation but will look into the
permanent solution when I get home." then that would have helped me a
lot with my uncertainty on this situation.
seem surprised when I ask for you show that there is work being down
on the permanent solution.
Well, yes, because:
“
When the current dependency was added, the conclusion was it would solve
all the cases because other implementations could add a Provides.
But at the end of the day, the bootstrap script will need to be fixed
”
In the end AIUI when the dependency was added it wasn't checked that
debootstrap would actually be able to look for the Provides.
Correct.
Some historical context: The feature was added in 2020 and the
dependency was last updated in 2021. It has 3-4 years for this problem
to surface.
It was chosen in a time were we had 2 new contenders for the sysusers
implementation. It was not (and is still not) reasonable nor sustainable
for me to maintain the list of sysuser implementations in a dependency.
I still stand by that decision.
In parallel, the systemd maintainers and the providers of these
alternatives discussed how to solve this and they came up with the
`standalone` variant, split systemd to provide standalone versions too
and they came up with the provides. As I recall, I was not involved in
that discussion (I would not have wanted to) and I can only assume
debootstrap was not thought of in that discussion. Not that I would have
remembered.
I would
expected debhelper maintainers to check whether debootstrap works. I'm
no debhelper nor debootstrap maintainer here.
That is an expectation I cannot and will not live up to. I do know what
will eventually become a problem for debootstrap and I cannot pass
everything by the debootstrap people "just to be safe".
I reject that responsibility you are trying shove on to me per
Constitution §2.1 bullet 1.
Now, I'm getting in the situation of a messenger between debhelper
and debootstrap. Now, if that's really what needs to be done to get
something going, let's do it...
Samuel
For what it is worth, I do not like this situation either. Not on my
side nor on what I have to push on to (de facto) you.
I do not want you middleman for me just as I do not want to be middleman
for you. What I want is for someone to solve this in a way that ensure I
do not get another request for updating that Dependency line because the
situation changed. But I do not want you to relay messages on my behalf,
because that implies that I am involved and I do not want to be.
For me, the ideal outcome is (in order of preference) is that I am
informed of either of these cases:
1. "Hi Niels. We solved it outside debhelper. The temporary work around
can now be removed and this bug can be closed."
2. "Hi Niels.
We have found a permanent solution were if we do a one time tweak
of the dependency in debhelper and set it to "..." then we can
handle this per port/architecture as needed without changing the
default installation for Linux and without debhelper needing to
change when we do our tweaks. It is cleared with the relevant
stakeholders and works with debootstrap, so none of them are going
to challenge this change.
Note: Explicitly adding opensysusers fails the "without debhelper
needing to change when we do our tweaks", since opensysusers can
be removed, or some port could come along and want another sysuser
implementation, etc."
With all that said and done, I believe I promised I would add the
dependency as temporary work around if you were working on the permanent
solution and you have showed me that you are.
Best regards,
Niels
