From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 7010C59CAF for ; Tue, 5 Apr 2016 01:20:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C6C41E087E; Tue, 5 Apr 2016 01:20:10 +0000 (UTC) Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D44F9E087A for ; Tue, 5 Apr 2016 01:20:09 +0000 (UTC) Received: by mail-oi0-f53.google.com with SMTP id w85so59559860oiw.0 for ; Mon, 04 Apr 2016 18:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:sender:date:from:to:cc:subject:mail-followup-to :mime-version:content-disposition:user-agent; bh=dCqE6PhwjB3Tf2VGSkGLhPyOm0imOVRz4Fk+97Wn2Nc=; b=ew5qK8q3kM+170ncMvf/Qcc0EXHrBT8MdNeRA3qiHA+Cn/kGegmtxt5Ug67jiND3v5 /McOXmzLhLgEIFbyNgDlrGpfAb/WgBQ5WV7HCoFkgbvobqA0Bm8TUR64TGonJJqJIdDZ 2rX23R3ZEH7dmYba4GOkTQHncSw1fhn4UaFfq/1vgkIaTGoNeDmut27LnTURcOJreRhm 3QdeTQyOcchq11m9Wj2BFw6gNSsX6q2uFQTH8qRHIZ+Pl/RGdaEU6LhKNwi+W7/U/W7I q6P9ENkmYcB2Fr9AKXk6LPZdSlvWg4a3krsxeAlM+DMgJweTEJutvrmnHl60LCMjfnVb 5ipw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:sender:date:from:to:cc:subject :mail-followup-to:mime-version:content-disposition:user-agent; bh=dCqE6PhwjB3Tf2VGSkGLhPyOm0imOVRz4Fk+97Wn2Nc=; b=jc00EUtXAAZbL/YNuqlN/s5taDs+nK7fV3R/yciYdnJy2i9HFZy3bHY1ciOdlhDMi0 6Vnpti+tBGSoa8BjS3r7sCu7K2QFM2JI0q3zIB4XFuEI+0Qw0U8KUjwz7S3QC4xd7zxO 1Pyh4WrFiY99nsOlGGf77ecCqGucUsxi2w9k+uWUf8urgQOISGN5Yk1qPkcIPpDB/aZ+ 4d8uDEeDk6S6vHEPmAWWCCJVzBEXvt2EZuxntUfj83A+kKx9+gZPVQVABdkSRocRSTBo bMAE/ZtuwIQW90/MJI4Dtl63j7SppsqfSMMgpTxnkD9e4KnewUkvLzl02osdVtIv0uHt 424A== X-Gm-Message-State: AD7BkJLTgPodYA+wtQx49LrEyROV3EPMlU0lFqaddWG9bTAKb5PuaInhgXW7Wf1PPOhQfw== X-Received: by 10.202.206.4 with SMTP id e4mr7238259oig.88.1459819208930; Mon, 04 Apr 2016 18:20:08 -0700 (PDT) Received: from linux1 (cpe-66-68-34-247.austin.res.rr.com. [66.68.34.247]) by smtp.gmail.com with ESMTPSA id e20sm9251535oic.19.2016.04.04.18.20.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Apr 2016 18:20:08 -0700 (PDT) Message-ID: <570312c8.1469ca0a.30985.5db1@mx.google.com> X-Google-Original-Message-ID: <20160405011959.GA8044@linux1.gaikai.biz,> Sender: William Hubbs Received: (nullmailer pid 8103 invoked by uid 1000); Tue, 05 Apr 2016 01:19:59 -0000 Date: Mon, 4 Apr 2016 20:19:59 -0500 From: William Hubbs To: gentoo development Cc: aballier@gentoo.org Subject: [gentoo-dev] usr merge Mail-Followup-To: gentoo development , aballier@gentoo.org Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NDin8bjvE/0mNLFQ" Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Archives-Salt: 083d0676-0cac-4b5a-b807-a14cdb78a7f4 X-Archives-Hash: df3c1494ea49191d4e3d442e37eb8ca2 --NDin8bjvE/0mNLFQ Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline All, I thought that since the usr merge is coming up again, and since I lost track of the message where it was brought up, I would open a new thread to discuss it. When it came up before, some were saying that the /usr merge violates the fhs. I don't remember the specifics of what the claim was at the time, (I'm sure someone will point it out if it is still a concern). I don't think creating usr merged stages would be that difficult. I think it would just be a matter of creating a new version of baselayout that puts these symlinks in place: /bin->usr/bin /lib->usr/lib /lib32->usr/lib32 /lib64->usr/lib64 /sbin->usr/bin /usr/sbin->bin Once that is in place in a new baselayout, I think portage's colission detection would be able to catch files that had the same names and were originally in different paths when building the new stages. I put some thought also in how to nigrate live systems, and I'm not sure what the best way to do that is. I wrote a script, which would do it in theory, but I haven't tested because I only have one system and if it breaks it the only way back would be to reinstall. The script is attached. Thoughts on any of this? William --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=usrmerge #!/bin/bb is_internal() { [ -z "$1" ] && return 1 case $(command -v $1) in */*) rc=1 ;; *) rc=0 ;; esac return $rc } run_command() { local dryrun= [ $DRYRUN -eq 1 ] && dryrun=echo $dryrun "$@" } for cmd in cp ln; do if ! is_internal $cmd; then echo "Please rebuild busybox and include the $cmd command." exit 1 fi done if [ -L /bin -a -L /sbin ]; then echo "It appears that the /usr merge has already been done on this system." exit 0 fi DRYRUN=1 HELP=0 while [ $# -gt 0 ]; do case $1 in --dryrun|--dry-run) DRYRUN=1 ;; -h|--help) HELP=1 ;; esac shift done if [ $HELP -eq 1 ]; then echo "$(basename $0) -h \| --help - displays this message" echo "$(basename $0) --dryrun \| --dry-run - show what would be done" exit 0 fi # copy binaries for dir in /bin /sbin /usr/sbin; do run_command cp -a $dir/* /usr/bin done # copy libraries for dir in /lib*; do [ -L $dir ] && continue run_command cp -a $dir/* /usr$dir done # Create the /usr merge compatibility symlinks for dir in /bin /sbin; do run_command rm -rf $dir run_command ln -s usr/bin $dir done run_command rm -rf /usr/sbin run_command ln -s bin /usr/sbin for dir in /lib*; do run_command rm -rf $dir run_command ln -s usr$dir $dir done --4Ckj6UjgE2iN1+kY-- --NDin8bjvE/0mNLFQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlcDErkACgkQblQW9DDEZTi3rACdEQddlvYSvcahdJtOxvORSupe JuUAn3vXIMbcnkXCC9r5zsvZImEto+pi =54p/ -----END PGP SIGNATURE----- --NDin8bjvE/0mNLFQ--