[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#914897: affects private debs too



Adam Borowski writes:
> Andreas Henriksson wrote:
>> On Wed, Nov 28, 2018 at 03:14:20PM +0000, Ian Jackson wrote:
>> > Julien Cristau writes ("Re: Bug#914897: debootstrap, buster:
>> > Please disabled merged /usr by default"):
>> [...]
>> > > I'd suggest that this should be fixed by not shipping any packages that
>> > > aren't built on buildds.
>> > 
>> > It would be quite a radical departure for Debian to no longer support
>> > "I built this package for my mate to install on their computer".
>>
>> For the case of locally built binaries, bringing any problem
>> that usrmerge would hit to the light would be preferable.
>
> Any checks you can do may test only packages that reached the Debian
> archive.  We can discipline DDs, be it by requiring source-only, or by
> catching misbuilt packages, but we can't do anything for local packages.
>
> And these in a good part are not based on Debian sources.
>
> I for one use a .deb package to distribute my .bashrc to machines under my
> control.  Joe from a derivative named Debuntituan provides an
> uber-proprietary-drivers package to his users.  Any PPA.  A company-wide
> repo.  Etc, etc.

Debian is not responsible how third parties build their packages.  We
don't even exclude /usr/local/bin from PATH when building packages...

(If you care about distributions not doing the same as Debian, one would
need to patch every package to build & work on both merged-/usr and
non-merged-/usr systems no matter what Debian does...)

> Thus: sorry but there is no way we can possibly support usrmerged and
> non-usrmerged systems at the same time.  Usrmerge is not viable without a
> flag day.

Oh, it's possible.  It makes life a bit harder than a flag day or clear
commitment to one setup, but so does supporting multiple init systems
(so the advantages of, for example, easier maintenance by having
declarative definitions is lost).

Regardless of debootstrap defaults or flag days, we could also consider
moving programs from /{s,}bin to /usr/{s,}bin with a compat symlink in
/{s,}bin; this does not need a flag day.  That is useful either way as:
a) some people will use /usr/bin/${x} instead of /bin/${x} anyway (they
don't have to come from Debian), and b) it would also make supporting
merged-/usr and non-merged-/usr simpler as the programs would always be
available in both locations.

Some packages such as iptables have already done this ad-hoc.

I'm toying around with ideas for a dh_usrmove tool which would allow to
easily add this to existing packages.  That would also allow to drop it
later in one go should one in the far future require the /bin ->
/usr/bin symlink.

Ansgar


Reply to: