Debian Bug report logs - #810301
merged /usr support for debootstrap

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Marco d'Itri <md@linux.it>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: merged /usr support for debootstrap

Date: Fri, 8 Jan 2016 05:50:11 +0100

[Message part 1 (text/plain, inline)]

Package: debootstrap
Version: 1.0.75
Severity: normal
Tags: d-i patch
User: md@linux.it
Usertags: usrmerge

After a discussion on #debian-boot it is my understanding that the d-i 
developers would prefer for debootstrap to create a merged /usr 
filesystem layout by default, and eventually add a d-i feature to enable 
the legacy layout.

While at this time it is not possible yet to create a merged /usr system 
without the dpkg hacks in the usrmerge package, I am publishing this 
patch for review.

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #10 received at submit@bugs.debian.org (full text, mbox, reply):

From: Marco d'Itri <md@linux.it>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Re: Bug#810301: merged /usr support for debootstrap

Date: Fri, 8 Jan 2016 06:43:20 +0100

[Message part 1 (text/plain, inline)]

And here comes the patch...

Please note that it must not be applied until it will be possible to 
uninstall the usrmerge package from a system having installed 
a reasonable selection of packages.

-- 
ciao,
Marco

[usrmerge2.diff (text/x-diff, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 810301@bugs.debian.org (full text, mbox, reply):

From: Christian PERRIER <bubulle@debian.org>

To: Marco d'Itri <md@linux.it>, 810301@bugs.debian.org

Subject: Re: Bug#810301: merged /usr support for debootstrap

Date: Fri, 8 Jan 2016 06:40:31 +0100

[Message part 1 (text/plain, inline)]

Quoting Marco d'Itri (md@linux.it):
> Package: debootstrap
> Version: 1.0.75
> Severity: normal
> Tags: d-i patch
> User: md@linux.it
> Usertags: usrmerge
> 
> After a discussion on #debian-boot it is my understanding that the d-i 
> developers would prefer for debootstrap to create a merged /usr 
> filesystem layout by default, and eventually add a d-i feature to enable 
> the legacy layout.
> 
> While at this time it is not possible yet to create a merged /usr system 
> without the dpkg hacks in the usrmerge package, I am publishing this 
> patch for review.

Hello Marco,

Looks like you forgot attaching the patch....

To other D-I developers (not to say "to Kibi") : I'm very tempted to
give full confidence in Marco's proposals (this one and the one
related to devices creation), apply these patches, upload and wait for
input. Any objection?

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 810301@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: Christian PERRIER <bubulle@debian.org>, 810301@bugs.debian.org

Cc: Marco d'Itri <md@linux.it>

Subject: Re: Bug#810301: merged /usr support for debootstrap

Date: Fri, 8 Jan 2016 08:05:31 +0100

[Message part 1 (text/plain, inline)]

Christian PERRIER <bubulle@debian.org> (2016-01-08):
> To other D-I developers (not to say "to Kibi") : I'm very tempted to
> give full confidence in Marco's proposals (this one and the one
> related to devices creation), apply these patches, upload and wait for
> input. Any objection?

I really think someone should check the a) from the quote below:
> Please let's agree on how to fix this, because trying to create the
> other useless devices:                                             
> a) is pointless, and                                               
> b) prevents running debootstrap in containers                      

debootstrap is not only used to install Debian on Debian, and being a
tad too aggressive with this removal might not be the best move forward.
On the other hand, making a change and getting some feedback from people
who got their stuff broken with it, possibly with patches, wouldn't be
/so/ bad.

Mraw,
KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 810301@bugs.debian.org (full text, mbox, reply):

From: Geert Stappers <stappers@stappers.nl>

To: 810301@bugs.debian.org

Subject: technical reason for "merged /usr support" in debootstrap

Date: Sat, 9 Jan 2016 19:18:42 +0100

Control: tag -1 moreinfo

On Fri, Jan 08, 2016 at 06:40:31AM +0100, Christian PERRIER wrote:
>
> To other D-I developers: I'm very tempted to give full confidence in
> Marco's proposals (this one and the one related to devices creation),
> apply these patches, upload and wait for input.
> Any objection?

Yes, I have several objections about the proposed change.

* It is not clear what problem is being fixed.

* No pointers to the discussion in the opening of this B.R.

* "I'm very tempted to give full confidence in Marco's proposals"
   is way too personal. It has no technical body.


So
__        ___          ___ 
\ \      / / |__  _   |__ \
 \ \ /\ / /| '_ \| | | |/ /
  \ V  V / | | | | |_| |_|
   \_/\_/  |_| |_|\__, (_)
                  |___/


If that might be "You can't have anymore /usr on seperate filesystem.",
then elaborate where debootstrap is aware of several filesytems.


Groeten
Geert Stappers
-- 
Leven en laten leven

Message #32 received at 810301@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: Geert Stappers <stappers@stappers.nl>, 810301@bugs.debian.org

Subject: Re: Bug#810301: technical reason for "merged /usr support" in debootstrap

Date: Sat, 9 Jan 2016 23:26:28 +0100

[Message part 1 (text/plain, inline)]

Control: tag -1 -moreinfo

On Jan 09, Geert Stappers <stappers@stappers.nl> wrote:

> * It is not clear what problem is being fixed.
It allows to support new use cases like OS snapshots, real read only OS 
filesystems, real shared (maybe networked) OS filesystems and stateless 
computers.
For a more detailed discussion of this I suggest that you consult
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ 
and read the discussion which has taken place on debian-devel@ in the 
last 10 days.

> * No pointers to the discussion in the opening of this B.R.
Well, I expected that there would not be the need to educate the d-i 
developers about widely discussed issues.

> If that might be "You can't have anymore /usr on seperate filesystem.",
It is not.

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #39 received at 810301@bugs.debian.org (full text, mbox, reply):

From: Christian PERRIER <bubulle@debian.org>

To: 810301@bugs.debian.org

Subject: Re: Bug#810301: technical reason for "merged /usr support" in debootstrap

Date: Sun, 10 Jan 2016 06:43:27 +0100

[Message part 1 (text/plain, inline)]

Quoting Geert Stappers (stappers@stappers.nl):

> * No pointers to the discussion in the opening of this B.R.

There's a lengthy discussion in -devel and this issue about merged
/usr is something I see floting around for years. 

Random picks in the said discussion seem to show a quite good agreement.

> 
> * "I'm very tempted to give full confidence in Marco's proposals"
>    is way too personal. It has no technical body.

For me, confidence in the respect of processes and other's opinion as
well as care to consider all possible aspects of difficult ttechnical
decisions is something I should grant to someone I've seen doing such
things in the project for years, even before I joined the project
myself...and including some technically difficult changes that may
impact the entire system.

So, yes, this is personal and I fully assume giving more credit to
Md's proposal and the way to push it than Joe Random Developer. That
has often be my way to work in the project and, surprisingly it works
faily well...particularly when dealing with issues I don't fully
understand (or, in this case, issues I have no enough free time to try
understanding).

[signature.asc (application/pgp-signature, inline)]

Message #44 received at 810301@bugs.debian.org (full text, mbox, reply):

From: Charles Plessy <plessy@debian.org>

To: 810301@bugs.debian.org

Subject: Re: Bug#810301: technical reason for "merged /usr support" in debootstrap

Date: Sun, 10 Jan 2016 21:25:43 +0900

Le Sun, Jan 10, 2016 at 06:43:27AM +0100, Christian PERRIER a écrit :
> Quoting Geert Stappers (stappers@stappers.nl):
> 
> > * No pointers to the discussion in the opening of this B.R.
> 
> There's a lengthy discussion in -devel and this issue about merged
> /usr is something I see floting around for years. 
> 
> Random picks in the said discussion seem to show a quite good agreement.

Hello everybody,

I read aproximately three quarters of the thread, plus some of the reference
documentation, and I agree that there is altogether a good agreement and that
objections are adequately answered.

Moreover, the patch set discussed here introduces the option "--no-merged-usr"
to keep the old behaviour of debootstrap.

So I think that Geert's objections are either answered or not valid.

Have a nice day,

Charles

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Message #49 received at 810301@bugs.debian.org (full text, mbox, reply):

From: Geert Stappers <stappers@stappers.nl>

To: 810301@bugs.debian.org

Subject: Re: Bug#810301: technical reason for "merged /usr support" in debootstrap

Date: Sun, 10 Jan 2016 14:28:19 +0100

[Message part 1 (text/plain, inline)]

On Sun, Jan 10, 2016 at 09:25:43PM +0900, Charles Plessy wrote:
> 
> So I think that Geert's objections are either answered or not valid.
> 

My objections were based on not knowing _why_ the change is needed.
I assumed a repair, meanwhile I understand it is about creating a possiblity,
a doorway to something new. I'll see what it will bring me.


Groeten
Geert Stappers
-- 
Leven en laten leven

[signature.asc (application/pgp-signature, inline)]

Message #54 received at 810301@bugs.debian.org (full text, mbox, reply):

From: Philip Hands <phil@hands.com>

To: Geert Stappers <stappers@stappers.nl>, 810301@bugs.debian.org

Subject: Re: Bug#810301: technical reason for "merged /usr support" in debootstrap

Date: Sun, 10 Jan 2016 17:02:22 +0100

[Message part 1 (text/plain, inline)]

Geert Stappers <stappers@stappers.nl> writes:

> On Sun, Jan 10, 2016 at 09:25:43PM +0900, Charles Plessy wrote:
>> 
>> So I think that Geert's objections are either answered or not valid.
>> 
>
> My objections were based on not knowing _why_ the change is needed.
> I assumed a repair, meanwhile I understand it is about creating a possiblity,
> a doorway to something new. I'll see what it will bring me.

Well done for being reasonable.

Thank you, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

[signature.asc (application/pgp-signature, inline)]

Message #59 received at 810301@bugs.debian.org (full text, mbox, reply):

From: Andreas Henriksson <ah@debian.org>

To: Cyril Brulebois <kibi@debian.org>

Cc: Christian PERRIER <bubulle@debian.org>, 810301@bugs.debian.org, Marco d'Itri <md@linux.it>

Subject: Re: Bug#810301: merged /usr support for debootstrap

Date: Tue, 5 Jul 2016 12:11:38 +0000

Hello!

On Fri, Jan 08, 2016 at 08:05:31AM +0100, Cyril Brulebois wrote:
> Christian PERRIER <bubulle@debian.org> (2016-01-08):
> > To other D-I developers (not to say "to Kibi") : I'm very tempted to
> > give full confidence in Marco's proposals (this one and the one
> > related to devices creation), apply these patches, upload and wait for
> > input. Any objection?
[...]

I'm personally keen on seeing this move forward. As far as I'm aware
there are no real blockers for this right now (since #817168 was recently
fixed). If you're aware of any issues please tell me and I'd be happy
to help out. Hoping to see us move forward on this very soon!

Regards,
Andreas Henriksson

Message #64 received at 810301@bugs.debian.org (full text, mbox, reply):

From: Marco d'Itri <md@linux.it>

To: Andreas Henriksson <ah@debian.org>

Cc: Cyril Brulebois <kibi@debian.org>, Christian PERRIER <bubulle@debian.org>, 810301@bugs.debian.org

Subject: Re: Bug#810301: merged /usr support for debootstrap

Date: Tue, 5 Jul 2016 14:13:09 +0200

[Message part 1 (text/plain, inline)]

On Jul 05, Andreas Henriksson <ah@debian.org> wrote:

> I'm personally keen on seeing this move forward. As far as I'm aware
> there are no real blockers for this right now (since #817168 was recently
> fixed). If you're aware of any issues please tell me and I'd be happy
> to help out. Hoping to see us move forward on this very soon!
Agreed, I think that is time to merge the patch.

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #69 received at 810301@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: Marco d'Itri <md@linux.it>, 810301@bugs.debian.org

Subject: Re: Bug#810301: merged /usr support for debootstrap

Date: Tue, 5 Jul 2016 16:04:39 +0200

[Message part 1 (text/plain, inline)]

Marco d'Itri <md@linux.it> (2016-01-08):
> +# Find out where the runtime dynamic linker and the shared libraries
> +# can be installed on each architecture: native, multilib and multiarch.
> +# This data can be verified by checking the files in the debian/sysdeps/
> +# directory of the glibc package.
> +#
> +# This function must be updated to support any new architecture which
> +# either installs the RTLD in a directory different from /lib or builds
> +# multilib library packages.
> +setup_merged_usr() {
> +	if [ "$MERGED_USR" = "no" ]; then return 0; fi
> +
> +	local link_dir
> +	case $ARCH in
> +	    hurd-*)	return 0 ;;
> +	    amd64)	link_dir="lib32 lib64 libx32" ;;
> +	    i386)	link_dir="lib64 libx32" ;;
> +	    mips|mipsel)
> +			link_dir="lib32 lib64" ;;
> +	    mips64*|mipsn32*)
> +			link_dir="lib32 lib64 libo32" ;;
> +	    powerpc)	link_dir="lib64" ;;
> +	    ppc64)	link_dir="lib32 lib64" ;;
> +	    ppc64el)	link_dir="lib64" ;;
> +	    s390x)	link_dir="lib32" ;;
> +	    sparc)	link_dir="lib64" ;;
> +	    sparc64)	link_dir="lib32 lib64" ;;
> +	    x32)	link_dir="lib32 lib64 libx32" ;;
> +	esac
> +	link_dir="bin sbin lib $link_dir"
> +
> +	local dir
> +	for dir in $link_dir; do
> +		ln -s usr/$dir $TARGET/$dir
> +		mkdir -p $TARGET/usr/$dir
> +	done
> +}
> +

I don't think having to play catch up with src:glibc is a good idea.
Can't that be determined automatically instead of hardcoding this
mapping?

Besides, this code means an unknown architecture doesn't get merged
/usr support. Is that intended/reasonable?

>  first_stage_install () {
> +	case $SUITE in
> +		etch|etch-m68k|jessie|lenny|squeeze|wheezy) ;;
> +		oldstable|stable) ;;
> +		*) setup_merged_usr ;;

This means “debootstrap stable” on stretch once it's released is going
to lead to different results compared to “debootstrap stretch”.


KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #74 received at 810301@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: Marco d'Itri <md@linux.it>, 810301@bugs.debian.org

Cc: debian-bsd@lists.debian.org, debian-hurd@lists.debian.org

Subject: Re: Bug#810301: merged /usr support for debootstrap

Date: Tue, 5 Jul 2016 21:39:33 +0200

[Message part 1 (text/plain, inline)]

[ Adding kfreebsd and hurd porters to the loop. ]

Cyril Brulebois <kibi@debian.org> (2016-07-05):
> Marco d'Itri <md@linux.it> (2016-01-08):
> > +# Find out where the runtime dynamic linker and the shared libraries
> > +# can be installed on each architecture: native, multilib and multiarch.
> > +# This data can be verified by checking the files in the debian/sysdeps/
> > +# directory of the glibc package.
> > +#
> > +# This function must be updated to support any new architecture which
> > +# either installs the RTLD in a directory different from /lib or builds
> > +# multilib library packages.
> > +setup_merged_usr() {
> > +	if [ "$MERGED_USR" = "no" ]; then return 0; fi
> > +
> > +	local link_dir
> > +	case $ARCH in
> > +	    hurd-*)	return 0 ;;

hurd porters, is that OK?

kfreebsd porters, what should we have here for your archs?

For those wondering (and AFAICT) it seems the only issue here is how to
handle multilib, since multiarch is “hidden” below usr/lib (in
usr/lib/<triplet> subdirectories).

> > +	    amd64)	link_dir="lib32 lib64 libx32" ;;
> > +	    i386)	link_dir="lib64 libx32" ;;
> > +	    mips|mipsel)
> > +			link_dir="lib32 lib64" ;;
> > +	    mips64*|mipsn32*)
> > +			link_dir="lib32 lib64 libo32" ;;
> > +	    powerpc)	link_dir="lib64" ;;
> > +	    ppc64)	link_dir="lib32 lib64" ;;
> > +	    ppc64el)	link_dir="lib64" ;;
> > +	    s390x)	link_dir="lib32" ;;
> > +	    sparc)	link_dir="lib64" ;;
> > +	    sparc64)	link_dir="lib32 lib64" ;;
> > +	    x32)	link_dir="lib32 lib64 libx32" ;;
> > +	esac
> > +	link_dir="bin sbin lib $link_dir"
> > +
> > +	local dir
> > +	for dir in $link_dir; do
> > +		ln -s usr/$dir $TARGET/$dir
> > +		mkdir -p $TARGET/usr/$dir
> > +	done
> > +}
> > +
> 
> I don't think having to play catch up with src:glibc is a good idea.
> Can't that be determined automatically instead of hardcoding this
> mapping?

Just checked with a regular porter, it doesn't seem crazy to expect
porters to come up with an extra patch for d-i/debootstrap support once
they're done bootstrapping their port. So, that addresses my initial
concern.

> Besides, this code means an unknown architecture doesn't get merged
> /usr support. Is that intended/reasonable?

Actually, this means an architecture which isn't listed doesn't get
extra paths, and /lib might be enough for some ports, e.g. arm64.

It would seem a better idea to list all ports explicitly though.

> >  first_stage_install () {
> > +	case $SUITE in
> > +		etch|etch-m68k|jessie|lenny|squeeze|wheezy) ;;
> > +		oldstable|stable) ;;
> > +		*) setup_merged_usr ;;
> 
> This means “debootstrap stable” on stretch once it's released is going
> to lead to different results compared to “debootstrap stretch”.

That part remains to be fixed.


KiBi.

[signature.asc (application/pgp-signature, inline)]

Message #79 received at 810301@bugs.debian.org (full text, mbox, reply):

From: Marco d'Itri <md@linux.it>

To: Cyril Brulebois <kibi@debian.org>, 810301@bugs.debian.org

Subject: Re: Bug#810301: merged /usr support for debootstrap

Date: Tue, 5 Jul 2016 21:37:20 +0200

[Message part 1 (text/plain, inline)]

On Jul 05, Cyril Brulebois <kibi@debian.org> wrote:

> > +	case $ARCH in
> > +	    hurd-*)	return 0 ;;
> > +	    amd64)	link_dir="lib32 lib64 libx32" ;;
[...]

> I don't think having to play catch up with src:glibc is a good idea.
> Can't that be determined automatically instead of hardcoding this
> mapping?
I double checked with the glibc people: this could be done with gcc 
-print-multi-lib, but I do not think that depending on gcc is an option 
(also: foreign deboostrap).

> Besides, this code means an unknown architecture doesn't get merged
> /usr support. Is that intended/reasonable?
This would be a (small) problem only for new architectures with multilib 
libraries, and I do not expect that we will have any more of these.
E.g. you can see that arm64 is not in the list since it does not use 
/lib64 for multilib, but only multiarch.

Also, this would not be a big deal anyway because these extra links are 
only needed to install multilib libraries, so if they will be needed at 
development time for a new architecture they can easily be created 
manually before installing the multilib libc package.

Also again, these links are only an interim workaround to support 
merged-/usr systems without rebuilding the library packages: I expect 
that in the future nobody would bother installing non-merged systems, so 
if we can drop support for that then we can just build the multilib libc 
packages to create the /lib64 symlinks themselves when installed.

> >  first_stage_install () {
> > +	case $SUITE in
> > +		etch|etch-m68k|jessie|lenny|squeeze|wheezy) ;;
> > +		oldstable|stable) ;;
> > +		*) setup_merged_usr ;;
> This means “debootstrap stable” on stretch once it's released is going
> to lead to different results compared to “debootstrap stretch”.
I know, but I expected that at some point close to the next release the 
"stable" keyword would be moved. Or is there a better approach?

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #84 received at 810301@bugs.debian.org (full text, mbox, reply):

From: Marco d'Itri <md@linux.it>

To: Cyril Brulebois <kibi@debian.org>, 810301@bugs.debian.org

Subject: Re: Bug#810301: merged /usr support for debootstrap

Date: Thu, 7 Jul 2016 14:46:36 +0200

[Message part 1 (text/plain, inline)]

On Jul 05, Cyril Brulebois <kibi@debian.org> wrote:

> For those wondering (and AFAICT) it seems the only issue here is how to
> handle multilib, since multiarch is “hidden” below usr/lib (in
> usr/lib/<triplet> subdirectories).
Indeed.

> Actually, this means an architecture which isn't listed doesn't get
> extra paths, and /lib might be enough for some ports, e.g. arm64.
I do not expect that we will get any other multilib ports.

> It would seem a better idea to list all ports explicitly though.
Why? See above.

> > >  first_stage_install () {
> > > +	case $SUITE in
> > > +		etch|etch-m68k|jessie|lenny|squeeze|wheezy) ;;
> > > +		oldstable|stable) ;;
> > > +		*) setup_merged_usr ;;
> > 
> > This means “debootstrap stable” on stretch once it's released is going
> > to lead to different results compared to “debootstrap stretch”.
> That part remains to be fixed.
Yes, but how? The current stable cannot work with a merged /usr, so 
I expected that this would be changed just before stretch is released.

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #89 received at 810301@bugs.debian.org (full text, mbox, reply):

From: Marco d'Itri <md@linux.it>

To: Cyril Brulebois <kibi@debian.org>, 810301@bugs.debian.org

Subject: Re: Bug#810301: merged /usr support for debootstrap

Date: Thu, 4 Aug 2016 15:27:59 +0200

[Message part 1 (text/plain, inline)]

On Jul 07, Marco d'Itri <md@linux.it> wrote:

> > > >  first_stage_install () {
> > > > +	case $SUITE in
> > > > +		etch|etch-m68k|jessie|lenny|squeeze|wheezy) ;;
> > > > +		oldstable|stable) ;;
> > > > +		*) setup_merged_usr ;;
> > > 
> > > This means “debootstrap stable” on stretch once it's released is going
> > > to lead to different results compared to “debootstrap stretch”.
> > That part remains to be fixed.
> Yes, but how? The current stable cannot work with a merged /usr, so 
> I expected that this would be changed just before stretch is released.
How do you want to continue?

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #94 received at 810301@bugs.debian.org (full text, mbox, reply):

From: Marco d'Itri <md@linux.it>

To: debian-boot@lists.debian.org, 810301@bugs.debian.org

Subject: Re: Bug#810301: merged /usr support for debootstrap

Date: Thu, 18 Aug 2016 09:17:41 +0200

[Message part 1 (text/plain, inline)]

How can we move forward with this?

On Aug 04, Marco d'Itri <md@linux.it> wrote:

> On Jul 07, Marco d'Itri <md@linux.it> wrote:
> 
> > > > >  first_stage_install () {
> > > > > +	case $SUITE in
> > > > > +		etch|etch-m68k|jessie|lenny|squeeze|wheezy) ;;
> > > > > +		oldstable|stable) ;;
> > > > > +		*) setup_merged_usr ;;
> > > > 
> > > > This means “debootstrap stable” on stretch once it's released is going
> > > > to lead to different results compared to “debootstrap stretch”.
> > > That part remains to be fixed.
> > Yes, but how? The current stable cannot work with a merged /usr, so 
> > I expected that this would be changed just before stretch is released.
> How do you want to continue?
> 
> -- 
> ciao,
> Marco

-- 
ciao,
Marco

[signature.asc (application/pgp-signature, inline)]

Message #99 received at 810301@bugs.debian.org (full text, mbox, reply):

From: Ansgar Burchardt <ansgar@debian.org>

To: 810301@bugs.debian.org

Cc: Marco d'Itri <md@linux.it>

Subject: Re: Bug#810301: merged /usr support for debootstrap

Date: Thu, 08 Sep 2016 15:36:54 +0200

On Thu, 7 Jul 2016 14:46:36 +0200 Marco d'Itri <md@linux.it> wrote:
> On Jul 05, Cyril Brulebois <kibi@debian.org> wrote:
> 
> > For those wondering (and AFAICT) it seems the only issue here is
how to
> > handle multilib, since multiarch is “hidden” below usr/lib (in
> > usr/lib/<triplet> subdirectories).
> Indeed.
> 
> > Actually, this means an architecture which isn't listed doesn't get
> > extra paths, and /lib might be enough for some ports, e.g. arm64.
> I do not expect that we will get any other multilib ports.
> 
> > It would seem a better idea to list all ports explicitly though.
> Why? See above.
> 
> > > >  first_stage_install () {
> > > > +	case $SUITE in
> > > > +		etch|etch-m68k|jessie|lenny|squeeze|wheezy) ;;
> > > > +		oldstable|stable) ;;
> > > > +		*) setup_merged_usr ;;
> > > 
> > > This means “debootstrap stable” on stretch once it's released
is going
> > > to lead to different results compared to “debootstrap
stretch”.
> > That part remains to be fixed.
> Yes, but how? The current stable cannot work with a merged /usr, so 
> I expected that this would be changed just before stretch is
released.

Could you use the "Codename" field from Release to normalize the suite
name?  That should work even when the meaning of "stable" changes.

(Which makes me wonder: does debootstrap check that the suite it is
asked to install is either in the Release file's Suite or Codename
field?)

Ansgar

Message #104 received at 810301@bugs.debian.org (full text, mbox, reply):

From: Ansgar Burchardt <ansgar@debian.org>

To: 810301@bugs.debian.org

Cc: Marco d'Itri <md@linux.it>

Subject: Re: Bug#810301: merged /usr support for debootstrap

Date: Thu, 08 Sep 2016 17:46:38 +0200

[Message part 1 (text/plain, inline)]

On Thu, 2016-09-08 at 15:36 +0200, Ansgar Burchardt wrote:
> Could you use the "Codename" field from Release to normalize the
> suite name?  That should work even when the meaning of "stable"
> changes.

I've updated Marco's patch to include this change and prepared
everything as a Git series. The patches below should be applied after
the one I provided for #837075.

Additional testing is of course welcome.

Ansgar

[0002-Merged-usr-support-for-debootstrap.patch (text/x-patch, attachment)]

[0003-Pass-k-to-tar-when-extracting-packages.patch (text/x-patch, attachment)]

[0004-Typo-conterparts-counterparts.patch (text/x-patch, attachment)]

[0005-Use-CODENAME-to-identify-suites-which-support-merged.patch (text/x-patch, attachment)]

[0006-Add-changelog-entry-for-merged-usr-support.patch (text/x-patch, attachment)]

Message #109 received at 810301-close@bugs.debian.org (full text, mbox, reply):

From: Steve McIntyre <93sam@debian.org>

To: 810301-close@bugs.debian.org

Subject: Bug#810301: fixed in debootstrap 1.0.83

Date: Tue, 13 Sep 2016 12:49:18 +0000

Source: debootstrap
Source-Version: 1.0.83

We believe that the bug you reported is fixed in the latest version of
debootstrap, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 810301@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Steve McIntyre <93sam@debian.org> (supplier of updated debootstrap package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Tue, 13 Sep 2016 13:16:41 +0100
Source: debootstrap
Binary: debootstrap debootstrap-udeb
Architecture: source all
Version: 1.0.83
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team <debian-boot@lists.debian.org>
Changed-By: Steve McIntyre <93sam@debian.org>
Description:
 debootstrap - Bootstrap a basic Debian system
 debootstrap-udeb - Bootstrap the Debian system (udeb)
Closes: 810301 837075 837185
Changes:
 debootstrap (1.0.83) unstable; urgency=medium
 .
   [ Ansgar Burchardt ]
   * functions: Validate that the requested suite is listed in the
     Release file's Suite or Codename field. (Closes: #837075)
   * Add support for merged-/usr, enabled by a new --merged-usr option.
     (Closes: #810301)
   * Feign install of dpkg in second stage. This avoids problems when
     using dpkg-deb together with busybox' tar. (Closes: #837185)
   * README: Use https://.
 .
   [ Steve McIntyre ]
   * Update Standards-Version to 3.9.8 (no changes needed)
Checksums-Sha1:
 6188946fc8ad972a5b720322623afb0d3d930559 1812 debootstrap_1.0.83.dsc
 e3dd550523fb8f30b5217df99e44cd9340bce6dd 65551 debootstrap_1.0.83.tar.gz
 761bb5d56a0364a33fcd9c0d996b874ac86f785c 18574 debootstrap-udeb_1.0.83_all.udeb
 17e5a6cdef48a16936644e9e5a63ca9f1e774f7f 65192 debootstrap_1.0.83_all.deb
Checksums-Sha256:
 203e64ff912d3a926d57515d7d1537a4e6c91e393eaa5344c8614f8424ce2fe5 1812 debootstrap_1.0.83.dsc
 64d571e8807643ce098e2c4eff0ce17ae246569f1f07224244649be36eaac6b4 65551 debootstrap_1.0.83.tar.gz
 877fe5281a0e424bd6c71d121cbb725b8f56694e66558cd47c20c3aa87ceff72 18574 debootstrap-udeb_1.0.83_all.udeb
 e9abe794bad681b184179e8ab04a41c5d1567cee082e4adc95ed61ad0dce084f 65192 debootstrap_1.0.83_all.deb
Files:
 a02f87d143eb0bed5ee4060162b13fe5 1812 admin extra debootstrap_1.0.83.dsc
 fa5a79d4fddeb50465a9506df9b464bc 65551 admin extra debootstrap_1.0.83.tar.gz
 5811209f3861f7b4ea0c08eb0b48b729 18574 debian-installer extra debootstrap-udeb_1.0.83_all.udeb
 e5e42bdbc243e2922c3f9fb367eab625 65192 admin extra debootstrap_1.0.83_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJX1/LOAAoJEFh5eVc0QmhOsWkQAI9x5weQwEwHfEceuwM/fKBu
RCXh2X01iDMnK4QxnMQemp+r0fNnwpCDjhcfKOzvcSiqTkzCFwXUiNJXdeX3s3tL
MhywDxZr4l7U7mdON5DKJkbN4PmI8P5XH41IeO5uXPet+1poUtg5OjkRoM/jTqjw
pvFNqLX8lNNiqL8rmuYQ+O2maJRxNgigVw76+UVr2eVz01qEIrmUfzmvx8DQJrnK
w3W7VX68ZMOZxCUH0rqaWlxsLuJzV7/TJHwtc71bxmkD6BtgtMHJdpw8idAJVFci
jwIW4sj1m/LtePSZBV+uQbRGxXcP41d84ogQASjQKejUMaPRtRx5X1qiG3p1hVeq
qEiw8Z/JYDej38Pa8ZQD1LKoH6H764EsmPeR0lNv/Zzqr5HGXkQo3gUTBWMLZk87
cdMuQfmJtmIA86yZSTTBfIUHcKnN8MOzLV9VesXVJ+M6ezYKk2TYKW8sdWbF4eAF
OdD95lQxt0tVtj3ioQHMnlYTmr3cWRBE1RTGNQNMlVrrxAMxOmgjleyIW3lRvIMc
CKo2CD+ndNsQVM6h4iDDIoh+VfAoYEu5+DepCBFIj/mWkQ69Mrtqz3l1vuMZQPSy
b1eWIBEXpovm+fZ9jmNPV+oWx/9F79n+zhjqfd7lvY6FwVhJbfUCxZ7Ic/pG/+As
pE2lFrUXFhY2wTrsEs3Y
=VC5c
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.