public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-portage-dev@lists.gentoo.org
Subject: [gentoo-portage-dev] Re: Is portage (/usr)/bin-merge safe?
Date: Sun, 2 Jun 2013 11:54:33 +0000 (UTC)	[thread overview]
Message-ID: <pan$9e06c$7a692942$4bfe2d1a$aea214bc@cox.net> (raw)
In-Reply-To: 51AB2921.2060906@gmail.com

vivo75@gmail.com posted on Sun, 02 Jun 2013 13:14:41 +0200 as excerpted:

> While portage can be safe, for various reason (including the resultant
> pkg) I do prefer to do the move in post_src_install() #1 All my tests
> have been done against a manually converted filesystem

That's what mine would be...

> #1 excerpt from bashrc, this code is rough but work in the gentoo
> ebuilds tree domain
> 
> move_root_to_usr() {

Thanks.  What I was thinking would actually reverse that (/bin being the 
real dir, /sbin being a symlink to it), given my (traditional sysadmin) 
pref for short paths, but I hadn't thought of a bashrc solution at all, 
so that gives me yet another way of doing it. =:^)

My first thought is that I prefer standard layout packages, however, 
easing interoperability should I decide to swap binpkgs with someone.  
(Yes, I'm aware of the security issues if the parties don't trust each 
other...)

But OTOH I think that solves issues such as path-based equery belongs, 
for instance.  Being amd64 for nearing a decade now (and no-multilib for 
several years of it), I'm used to worrying about that with the symlinked 
lib/lib64 thing, and that's the one thing I wasn't looking forward to 
with unified bins.  (I think I'll keep bin/sbin separate at first, see 
how bin/usr-bin go first, then think about bin/sbin.)

But if your bashrc solution /does/ solve the equery belongs path thing I 
might well use it on lib/lib64 as well...  (Either that or since I 
believe the libs are a profile thing and I'm already running a heavily 
modified profile, no @system for instance, I could probably simply modify 
that...  Actually, that's probably a better solution in any case, since 
it's just undoing mainline settings the same way mainline does them in 
the first place.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman



  reply	other threads:[~2013-06-02 11:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-01  5:36 [gentoo-portage-dev] Is portage (/usr)/bin-merge safe? Duncan
2013-06-01  5:49 ` Zac Medico
2017-12-07  8:37   ` [gentoo-portage-dev] " Duncan
2017-12-07  9:07     ` Zac Medico
2017-12-07 12:14       ` Duncan
2013-06-01  6:17 ` [gentoo-portage-dev] " Mike Frysinger
2013-06-02 11:14 ` vivo75
2013-06-02 11:54   ` Duncan [this message]
2013-06-02 12:47     ` [gentoo-portage-dev] " vivo75
2013-06-02 13:19       ` Duncan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='pan$9e06c$7a692942$4bfe2d1a$aea214bc@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=gentoo-portage-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox