Le jeudi, 21 février 2019, 15.28:23 h CET Ian Jackson a écrit :
> Back in the wider world, of course many people build packages on
> Debian systems for installation `somewhere else'. I have done it
> myself and probably many of the people reading this message have too.
>
> What is implicitly going on here is that it is mostly-tacitly[2] being
> assumed (or declared) that `I built this .deb on my laptop[1] and gave
> it to my friend' is wrongheaded.
I don't think it is wrongheaded, but I do think that assuming that it is meant
to work consistently under any circumstances, is. There are _so many_
circumstances that make this exercise error-prone:
"I built this amd64 .deb and gave it to my friend for use on their RasbperryPi
arm64 host"
"I built this .deb on my laptop on which I had installed a /usr/local/bin/
grep"
"I built this .deb an gave it to my friend who runs CentOS"
etc
> I don't think doing that is wrongheaded. Certainly it is extremely
> common; we don't have any public pronouncements saying it is somehow
> wrong; and we have had little discussion where we as a project decided
> that this was now a use case which we feel free to just break.
Frankly, while it's not _broken_ per se, it is and has always really been
fragile. True, merged-/usr arguably worsens _one_ aspect of building packages
on one's host, but in ways that are really easy to detect, and warn for.
> Personally I think that this is a very important thing to keep
> working. It is the very core of users' collective software freedom.
You seem to be conflating "building on one's host" with "outside of any
chroot", and equating this with "users' collective software freedom" is really
making your point a disservice. Being able to improve, build and share binary
artifacts of free software is _vital_, and the whole point of building
software distributions in the first place, but insisting that these rights are
only "truly" exercised when builds are done outside of chroots is
disingenuine. .deb packages already have to be built using certain tools, so
we do set the limit (of what minimal set of tools are mandatory) somewhere,
and my point is that this limit might not be at the right place. I'd be
totally OK with saying "the only supported way to build .deb packages from
buster on is using by pdebuild; however, you _can_ use dpkg-buildpackage
alone, but be aware (and you'll get warnings) that this can lead to building
.deb packages with undesireable properties." The second half of the sentence
is already true, and has always been; we probably just failed at communicating
it sufficiently clearly.
> And that software freedom needs to be easy to exercise in practice.
> Despite a lot of excellent tooling, chroots are still not entirely
> trivial to set up and maintain.
Then that's maybe what we should be fixing.
> I would invite the TC to read this manpage, which is trying to explain
> to a Debian user how to change the programs on their own computer
> https://manpages.debian.org/stretch-backports/dgit/dgit-user.7.en.html
> and then consider how much even worse it would be if we had to write
> about chroots too.
Perhaps dpkg-buildpackage should be grown to build in a chroot by default? Or
get an option to do that?
Really, I think we should stop considering that .debs built outside of
"controlled environments" are more than temporary software transports. Our
"standard" package building tools should build in such environments by
default.
> To TC members who are minded to uphold the current approach, I would
> ask: can you please explicitly state your opinion on this ? That is:
>
> Is it OK for a Debian user to build .deb on their laptop and give it
> to their friend ?
Yes; provided that said .deb is built in a sane (sanitized / controlled)
environment. As you're talking about non-chroot builds; it is OK, provided
that the tools warn about that. In that area, I think the "Build-Tainted-By"
are steps in the right direction.
> If it is OK, how will we make sure that it does not pointlessly break ?
As it is already broken in many ways, your question is biased. But I think the
good way is to normalize "proper builds", by making sure our standard tools
"do the right thing" by default.
> I readily admit that there are many ways that this can produce a
> result significantly different to the official Debian package,
> particularly because the package build system may configure itself
> differently in the the presence of unexpected. The resulting package
> is probably not going to be suitable for wide distribution.
>
> But those kind of problems are (a) not serious in practice
> (b) generally have obvious symptoms and (c) are easily worked around
> by various means. Working around a usrmerge-generated failure is
> difficult; it usually involves doing serious violence to the upstream
> build system, or perhaps horrific rules file bodges.
Given a Build-Tainted-By flag in the binary artifacts, dpkg could outright
refuse to unpack on a host without the symlinks, or spit a warning, or
recommend installing usrmerge. For me, you're painting it as much worse than
it _really_ is; for various reasons:
a) it's already _really_ easy to get heavily broken packages by just landing
some scripts in /usr/local/bin; if these paths get embedded in the fixed paths
of the software, these failures are at least as hard to find.
b) out of all our source packages, only 64 have shown to have problems caused
by merged-/usr (of which 29 are left). That's a _really low_ number. I'd be
genuinely curious to see how many get broken by the presence of a noop /usr/
local/bin/grep (but would expect the number to be at least an order of
magnitude larger).
Cheers,
OdyXAttachment:
signature.asc
Description: This is a digitally signed message part.