On Mon, 01 Feb 2021 at 13:35:28 +0100, Adam Borowski wrote:
> On Sun, Jan 31, 2021 at 03:34:27PM -0600, Gunnar Wolf wrote:
> > I want to state (and not as part of the vote, but just as
> > yet another DD) that the only way I feel makes sense to continue now
> > is via Simon's ① option: Symlinking
On Feb 01, Adam Borowski wrote:
> I'd strongly urge the opposite order: FIRST decree that no package may
> ship any file to non-canonical path (ie, have dpkg extract anything over
> a symlink), and only then flip the switch.
There is no "switch": this decision only certifies what we have been
On Sun, Jan 31, 2021 at 03:34:27PM -0600, Gunnar Wolf wrote:
> ...And to be clear: We at the TC are *not* doing detailed design
> work. But I want to state (and not as part of the vote, but just as
> yet another DD) that the only way I feel makes sense to continue now
> is via Simon's ① option:
Sean Whitton writes:
> ===BEGIN
> The Technical Committee resolves that Debian 'bookworm' should support
> only the merged-usr root filesystem layout, dropping support for the
> non-merged-usr layout.
>
> Until after the release of 'bullseye', any implementation of this
> resolution must be done
Hola Sean Whitton!
> ===BEGIN
> The Technical Committee resolves that Debian 'bookworm' should support
> only the merged-usr root filesystem layout, dropping support for the
> non-merged-usr layout.
>
> Until after the release of 'bullseye', any implementation of this
> resolution must be done
On Mon, Jan 25, 2021 at 11:45:55AM -0700, Sean Whitton wrote:
> Dear Technical Committee members,
>
> I call for votes on the following ballot to resolve #978636. The voting
> period starts immediately and lasts for up to one week, or until the
> outcome is no longer in doubt (§6.3.1).
>
>
Gunnar Wolf dijo [Sun, Jan 31, 2021 at 03:32:02PM -0600]:
> My vote is:
>
> Y > F > N
...And to be clear: We at the TC are *not* doing detailed design
work. But I want to state (and not as part of the vote, but just as
yet another DD) that the only way I feel makes sense to continue now
is via
Sean Whitton dijo [Mon, Jan 25, 2021 at 11:45:55AM -0700]:
> ===BEGIN
> The Technical Committee resolves that Debian 'bookworm' should support
> only the merged-usr root filesystem layout, dropping support for the
> non-merged-usr layout.
>
> Until after the release of 'bullseye', any
On Mon, Jan 25, 2021 at 11:45:55AM -0700, Sean Whitton wrote:
> ===BEGIN
> The Technical Committee resolves that Debian 'bookworm' should support
> only the merged-usr root filesystem layout, dropping support for the
> non-merged-usr layout.
>
> Until after the release of 'bullseye', any
On Mon, 25 Jan 2021 at 11:45:55 -0700, Sean Whitton wrote:
> ===BEGIN
> The Technical Committee resolves that Debian 'bookworm' should support
> only the merged-usr root filesystem layout, dropping support for the
> non-merged-usr layout.
>
> Until after the release of 'bullseye', any
On Tue, 2021-01-26 at 13:17 +0200, Wouter Verhelst wrote:
> We can (and should, IMO) declare *today* that for bookworm, shipping
> files in / (as opposed to /usr) that are not compatibility symlinks
> will be RC.
I fear we are drifting away from just deciding to move to merged-/usr
to
On Tue, 26 Jan 2021 at 12:17:37 -0600, Gunnar Wolf wrote:
> Wouter Verhelst dijo [Tue, Jan 26, 2021 at 01:17:38PM +0200]:
> > We can (and should, IMO) declare *today* that for bookworm, shipping
> > files in / (as opposed to /usr) that are not compatibility symlinks will
> > be RC.
>
> I agree
Hi,
On Tue, Jan 26, 2021 at 3:45 AM Wouter Verhelst wrote:
>
> You can start writing a lintian check today
Here is a Lintian check that follows Ansgar's specification in the
second d-d thead. Of course, it will not be merged until the project
works out a suitable consensus on this controversial
Wouter Verhelst dijo [Tue, Jan 26, 2021 at 01:17:38PM +0200]:
> On Tue, Jan 26, 2021 at 12:28:45AM +0100, Marco d'Itri wrote:
> > Also, as is has been discussed, if the /usr/doc/ transition was
> > representative then this would probably take many years.
>
> You keep using that as an argument. I
Hi,
Simon McVittie writes:
> Should we be more specific than this in what we vote on, to avoid
> later having to adjudicate between developers who say that a particular
> implementation is or isn't merged-usr?
>
> Some developers seem to be using "merged /usr" to refer to multiple
> concrete
On Tue, 2021-01-26 at 13:17 +0200, Wouter Verhelst wrote:
> On Tue, Jan 26, 2021 at 12:28:45AM +0100, Marco d'Itri wrote:
> > Also, as is has been discussed, if the /usr/doc/ transition was
> > representative then this would probably take many years.
>
> You keep using that as an argument. I
On Tue, Jan 26, 2021 at 12:28:45AM +0100, Marco d'Itri wrote:
> Also, as is has been discussed, if the /usr/doc/ transition was
> representative then this would probably take many years.
You keep using that as an argument. I think it's very disinginuous to
point to a problem Debian had over 20
Adam Borowski writes:
> On Mon, Jan 25, 2021 at 11:45:55AM -0700, Sean Whitton wrote:
>> Dear Technical Committee members,
>>
>> I call for votes on the following ballot to resolve #978636. The voting
>> period starts immediately and lasts for up to one week, or until the
>> outcome is no
On Tue, 26 Jan 2021 at 11:27:07 +0100, Bastian Blank wrote:
> Before unpacking those packages, both /bin and /lib symlinks must
> already exist, because it's past the cutoff date of non-aliased support.
I would like that to become true, but the cutoff date of non-aliased
support has not yet
On Tue, Jan 26, 2021 at 09:56:46AM +, Simon McVittie wrote:
> Oh, I see. So when you say "both" in 1a, you're referring to the overall
> system - like the fact that we have both /bin/bash and /usr/bin/perl.
Yes.
> I don't see how we can force all packages to only ship files in /usr/*
> (your
On Mon, 25 Jan 2021 at 21:22:29 +, Simon McVittie wrote:
> On Mon, 25 Jan 2021 at 11:46:35 -0700, Sean Whitton wrote:
> > > The Technical Committee resolves that Debian 'bookworm' should support
> > > only the merged-usr root filesystem layout, dropping support for the
> > > non-merged-usr
On Tue, 26 Jan 2021 at 10:30:34 +0100, Bastian Blank wrote:
> On Tue, Jan 26, 2021 at 09:01:12AM +, Simon McVittie wrote:
> > On Tue, 26 Jan 2021 at 08:02:06 +0100, Bastian Blank wrote:
> > > Aren't there two sub-solutions?
> > >
> > > 1a. with packages shipping files both in /bin und
On Mon, 25 Jan 2021 at 14:47:56 -0800, Keith Packard wrote:
> I think that and a transition plan are both key to this project. I
> recently installed Debian from scratch on my HiFive unmatched board and
> it got merged / and /usr.
That ship has already sailed: on #914897 in 2019, before Debian
On Tue, Jan 26, 2021 at 09:01:12AM +, Simon McVittie wrote:
> On Tue, 26 Jan 2021 at 08:02:06 +0100, Bastian Blank wrote:
> > On Mon, Jan 25, 2021 at 09:22:29PM +, Simon McVittie wrote:
> > > Some developers seem to be using "merged /usr" to refer to multiple
> > > concrete layouts:
> > >
On Tue, 26 Jan 2021 at 08:02:06 +0100, Bastian Blank wrote:
> On Mon, Jan 25, 2021 at 09:22:29PM +, Simon McVittie wrote:
> > Some developers seem to be using "merged /usr" to refer to multiple
> > concrete layouts:
> > 1. an arrangement where all regular files that have traditionally been
> >
On Mon, Jan 25, 2021 at 09:22:29PM +, Simon McVittie wrote:
> Some developers seem to be using "merged /usr" to refer to multiple
> concrete layouts:
> 1. an arrangement where all regular files that have traditionally been
>in /bin, /sbin, /lib and /lib64 are physically located in /usr,
>
Simon McVittie writes:
> Should we be more specific than this in what we vote on, to avoid
> later having to adjudicate between developers who say that a particular
> implementation is or isn't merged-usr?
I think that and a transition plan are both key to this project. I
recently installed
On Jan 25, Simon McVittie wrote:
> 2. an arrangement where all regular files that have traditionally been
>in /bin, /sbin, /lib and /lib64 are physically located in /usr,
>with /bin etc. becoming "symlink farms" containing symlinks like
>/bin/sh -> /usr/bin/sh, /lib/ld-linux.so.2 ->
On Mon, Jan 25, 2021 at 11:45:55AM -0700, Sean Whitton wrote:
> Dear Technical Committee members,
>
> I call for votes on the following ballot to resolve #978636. The voting
> period starts immediately and lasts for up to one week, or until the
> outcome is no longer in doubt (§6.3.1).
>
>
On Mon, 25 Jan 2021 at 11:46:35 -0700, Sean Whitton wrote:
> > The Technical Committee resolves that Debian 'bookworm' should support
> > only the merged-usr root filesystem layout, dropping support for the
> > non-merged-usr layout.
Should we be more specific than this in what we vote on, to
Hello,
On Mon 25 Jan 2021 at 11:45AM -07, Sean Whitton wrote:
> I call for votes on the following ballot to resolve #978636. The voting
> period starts immediately and lasts for up to one week, or until the
> outcome is no longer in doubt (§6.3.1).
>
> ===BEGIN
> The Technical Committee
Dear Technical Committee members,
I call for votes on the following ballot to resolve #978636. The voting
period starts immediately and lasts for up to one week, or until the
outcome is no longer in doubt (§6.3.1).
===BEGIN
The Technical Committee resolves that Debian 'bookworm' should support
Am Di., 29. Dez. 2020 um 17:39 Uhr schrieb Marco d'Itri :
>
> On Dec 29, Ansgar wrote:
>
> > as suggested in [1], I would like to see Debian to move to support
> > only the merged-usr filesystem layout. This would simplfy things for
> > the future and also address the problem with installing
On Dec 29, Ansgar wrote:
> as suggested in [1], I would like to see Debian to move to support
> only the merged-usr filesystem layout. This would simplfy things for
> the future and also address the problem with installing files under
> aliased trees that dpkg has to do for both variants to be
Package: tech-ctte
X-Debbugs-Cc: debian-de...@lists.debian.org
Hi,
as suggested in [1], I would like to see Debian to move to support
only the merged-usr filesystem layout. This would simplfy things for
the future and also address the problem with installing files under
aliased trees that dpkg
35 matches
Mail list logo
