Bug 453468

Summary:	app-emulation/lxc-0.8.0-r1 should conditionally RDEPEND on dev-util/debootstrap sys-apps/yum
Product:	Gentoo Linux	Reporter:	Walter <walter>
Component:	Current packages	Assignee:	Diego Elio Pettenò (RETIRED) <flameeyes>
Status:	RESOLVED WONTFIX
Severity:	major	CC:	dev-zero, virtualization
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

Description Walter 2013-01-22 04:09:58 UTC

It feels to me like USE flags should be created to allow debootstrap and yum to be explicit dependencies for lxc.

Situation encountered:
 - hit a bug in dev-util/debootstrap-1.0.44 where it fails to validate GPG signatures .. ie. totally fails (see https://bugs.gentoo.org/show_bug.cgi?id=387565)
 - this is affecting the use of my scripts which rely on lxc
 - this will affect others, therefore we should desire an in-portage-tree fix
 - bad versions of debootstrap should be masked
 - masking should probably occur within debootstrap itself (rather than here)
 - there is no way to tell lxc that i explicitly require debian guest generation support, and therefore debootstrap, and therefore that i have a problem and need to upgrade my debootstrap to a working revision of the package (not yet available)

Reproducible: Always

Steps to Reproduce:
1. emerge lxc
2. lxc-create -n debian -t debian
Actual Results:  
Fail due to GPG keyring not up to date type errors.

Expected Results:  
Step (1), when called with the appropriate USE flag, installs a non-broken version of debootstrap for me (once available), avoiding the issue.

IMHO, the possible view that yum and debootstrap should not be USE-flag controlled dependencies is a weak one that breaks expected portage functionality (Gentoo's best and most central feature) for the package users.

Comment 1 Diego Elio Pettenò (RETIRED) gentoo-dev

2013-01-22 14:45:08 UTC

No I really don't think that adding USE flags for these deps is a good idea. There's already an elog that tells people that they need them for the related scripts.

Comment 2 Walter 2013-01-23 01:25:57 UTC

So err, given the example where outputting-to-human rather than being computationally-explicit (as a general rule, always a good idea) breaks expected portage functionality... how can you justify that view?