Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
On Fri, 19 May 2023 at 01:30, Simon Richter <sjr@debian.org> wrote:
>
> Hi,
>
> On 5/18/23 18:08, Luca Boccassi wrote:
>
> >> Without it, leaving them in place makes no difference for usrmerged
> >> systems, and allows derived distributions that don't need usrmerge to
> >> continue using our packages.
>
> > Not quite. Having packages only ship files under /usr (and possibly
> > /etc) is very much a goal in itself for a lot of us.
>
> My point is: that is not an end goal, because it provides no real
> tangible benefit on its own.
For yourself. Again, for others, it is and it does.
> It does make sense in the context of building immutable images, which is
> *also* a bootstrapping problem, and probably worth being supported with
> proper tooling.
>
> >> - there is no guarantee that usrmerge will be permanent or the last
> >> transition of this kind
>
> > It is permanent, there are several upstream projects that will drop
> > support for legacy layouts very soon, and it will not be re-added
> > back.
>
> You are currently building a "legacy" system, it will just take a bit of
> time to reach that status. The less you anticipate future needs, the
> faster this will be.
>
> I understand that you are also a member of one of these upstream
> projects, and that you are taking the interests of this project to
> "pretty much the last relevant holdout" here. Has it occurred to you
> that you are also wearing a Debian hat, and you could be taking the
> interests of the Debian project to said upstream project?
Has it occurred to you that there might be a specific reason why said
upstream project has kept compatibility with legacy cruft that only
benefits Debian for so many years, at non-zero cost for developers,
despite everything else that's relevant having long since moved on? It
is really not difficult to find out what that reason might be, and
would have been better to do so before throwing around such
accusations. And if you can't find it, you can always go to one of the
numerous available channels and ask other maintainers. Why don't you
do that, ask how come support for Debian stable for this and many
other aspects is kept intact and who's behind that effort, and report
back the answer?
> >> - it also solves the bootstrap problem
>
> > It also is the least likely to succeed, and the most likely to cause
> > significant "social" upheavals.
>
> The only social problem I see is that you are trying to create a
> situation in which other people are compelled to do your work for you if
> they want it to be done properly.
No, the social problem is that there is one maintainer who is allowed
to ignore the TC and roadblock the entire distribution, so that
something that's been trivially and quickly done pretty much literally
everywhere else is instead made incredibly difficult and long-winded.
But despite that, we are getting there, slow and steady, and
remarkably well given the difficult circumstances outwith our control.
> So far, you have been throwing out "solutions", and left the analysis of
> the feasibility of those to other people, then, after three iterations,
> you demanded a full write-up of all existing use cases and blanket
> permission to ignore anything not brought up in this list.
I have literally no idea what you are talking about. I have
contributed what I can in my spare time, unblocking the transition
last year and helping out Helmut and others this year. This is not my
day job, by the way. What have you done to help, precisely?
> The thing is: I see more enthusiasm and self-directed problem solving
> skills from the interns at the company where I work, and at the same
> time you are one of the top contributors of the upstream project whose
> ideas of a "supported" configuration we are supposed to follow.
I seriously do not appreciate your tone, you are out of line. Please stop.
Kind regards,
Luca Boccassi
Reply to: