[gentoo-dev] Re: check-reqs* vs CFLAGS=-g

[Duncan]

Michał Górny posted on Thu, 01 Aug 2013 13:33:48 +0200 as excerpted:

> LLVM has peek build space consumption around:
> 
> - 400-550M without clang (depending on targets),
> - 950-1200M with clang,
> - 16G with clang & USE=debug (assertions, checks).

Ouch!

Thanks for the heads-up.  I didn't realize -g/debug added THAT much!  For 
sure I'll have to keep that in mind if I ever decide to build llvm with 
debug... and the general rule in mind for building anything else with 
debug.

-- 
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

Re: [gentoo-dev] Re: RFC: toolchain-r1.eclass

[Donnie Berkholz]

On 22:30 Thu 25 Jul , Ryan Hill wrote:
> I don't think we will be moving to 5 very soon.  I have nothing 
> against it but Mike might be a harder sell.  I want USE deps so I'm 
> going to do 2 at least, then get the prefix guys on board for 3.

The council deprecated 1/2 in April so I'd avoid those.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux 
Analyst, RedMonk 


pgpk8YyXSSTTY.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Luca Barbato]

On 01/08/13 23:53, Michał Górny wrote:
> That would be a lot of effort if upstream doesn't accept it and we end
> up patching it all the way...

kmod isn't complex and probably could be made even a bit more compact,
considering also the pace of its development and the kind of changes in
the last month I doubt would be so incredible.

b6adccd6ff819b8befc48ede41a13f2201dce443 is quite enlightening on which
are their best practises anyway.

lu

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Michał Górny]

Dnia 2013-08-01, o godz. 23:03:11
Luca Barbato  napisał(a):

> On 01/08/13 19:46, Pacho Ramos wrote:
> > El jue, 01-08-2013 a las 18:11 +0200, Luca Barbato escribió:
> >> On 01/08/13 17:36, Michał Górny wrote:
> >>> So esystemd and ekmod now?
> >>
> >> You know my stance on systemd, for me it is a jumble of bad and
> >> interesting ideas not so soundly implemented, I do not have much time or
> >> will to play with that thing.
> >>
> >> kmod on the other hand had a pressing issue and getting it fixed-ish
> >> took about an evening while having Federico see around it.
> >>
> >> lu
> >>
> > 
> > But, what are the advantages of putting a lot of effort in keeping
> > static libs for udev?
> 
> A lot of effort means not using random-clashing-names, not keeping
> functions around just because.

That would be a lot of effort if upstream doesn't accept it and we end
up patching it all the way...

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Luca Barbato]

On 01/08/13 19:54, Samuli Suominen wrote:
> still, first the patch goes upstream and after upstream review and 
> commit to git it goes in tree otherwise we opt to the fallback and
> disable udev from lvm2/cryptsetup when USE=static is enabled (like
> cryptsetup upstream suggested to me) gentoo-specific patches mangling
> namespace of udev, kmod, whatever doesn't sound good at all however
> working it with upstream sounds great

I just spent an evening introducing a friend willing to have a look the
codebase. My solution to the problem of clashing symbols had been 3 fold:

- many functions are small and already inline, they are using in the
tool (bad practice IMHO) and in the library once. Making them static is
easy and works.

- some functions are using inside the library a couple of times, adding
an (ugly) privkm_ is enough to avoid the problem.

- some functions were used just in the tool and not in the library,
moved where it belongs.

Instead of running around in circles screaming static linking is unholy
fixing it that way wouldn't had take much...

I won't expect upstream picking up what Federico wrote anytime out of
pride more than technical merit.

lu

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Luca Barbato]

On 01/08/13 19:46, Pacho Ramos wrote:
> El jue, 01-08-2013 a las 18:11 +0200, Luca Barbato escribió:
>> On 01/08/13 17:36, Michał Górny wrote:
>>> So esystemd and ekmod now?
>>
>> You know my stance on systemd, for me it is a jumble of bad and
>> interesting ideas not so soundly implemented, I do not have much time or
>> will to play with that thing.
>>
>> kmod on the other hand had a pressing issue and getting it fixed-ish
>> took about an evening while having Federico see around it.
>>
>> lu
>>
> 
> But, what are the advantages of putting a lot of effort in keeping
> static libs for udev?

A lot of effort means not using random-clashing-names, not keeping
functions around just because.

> Looks like nothing really need them, and even
> Debian (that doesn't use systemd by default) drops them

Robbat said he wants to keep the stuff working, thus I lent him an hand
while introducing a friend to a small codebase with a good number of
practices I consider faulty but sort of easy to fix.

lu

Re: [gentoo-dev] How to know packages providing files under some directory

[Pacho Ramos]

El mié, 31-07-2013 a las 21:34 +0200, Pacho Ramos escribió:
> El mié, 31-07-2013 a las 15:19 -0400, Mike Gilbert escribió:
> > On Wed, Jul 31, 2013 at 3:17 PM, Pacho Ramos  wrote:
> > > El mié, 31-07-2013 a las 12:11 -0700, Zac Medico escribió:
> > >> On 07/31/2013 12:03 PM, Pacho Ramos wrote:
> > >> > I would like to know if there is any kind of DB to check for packages
> > >> > providing files under a directory. Does any exist?
> > >>
> > >> portageq owners / /path/to/directory
> > >
> > > But, doesn't it force me to try to merge all packages in the tree?
> > >
> > >
> > 
> > http://www.portagefilelist.de
> > 
> > And related package app-portage/pfl
> > 
> > 
> 
> But looks like it lets me find exact files, not directories 
> 
> (Anyway thanks for the info, didn't know it)
> 
> 
> 

Running portageq in the system providing:
http://tinderbox.dev.gentoo.org/default-linux/

would be enough... who is the owner of that one?

Thanks

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[William Hubbs]

On Thu, Aug 01, 2013 at 07:36:12PM +0200, Michał Górny wrote:
> Dnia 2013-08-01, o godz. 13:32:28
> Rich Freeman  napisał(a):
> 
> > On Thu, Aug 1, 2013 at 11:36 AM, Michał Górny  wrote:
> > > Dnia 2013-08-01, o godz. 17:17:35
> > > Luca Barbato  napisał(a):
> > >
> > >> On 01/08/13 17:04, William Hubbs wrote:
> > >> > There is a hack in our udev and kmod ebuilds that makes it possible to
> > >> > build the static libraries, but I think we should remove that hack 
> > >> > since
> > >> > upstream bans building them.
> > 
> > Thanks for the clarification - that makes sense.
> > 
> > >> Anyway I volunteered Federico to sort out this mess and he got that part
> > >> more or less done.
> > >>
> > 
> > If you're willing to do the work I think the teams should be willing
> > to allow you to support the necessary changes.  That is, assuming that
> > the changes aren't so intrusive that they create a real potential for
> 
> If only people were that keen to fix the core issue. That is, to fix
> static linking on Linux and make it useful without two batches of hacks
> on top of it.
 
 I wouldn't have put it this way, but yes, I have to agree with mgorny
 here. the real fix is in binutils.
 It needs to be fixed to support static linking and visibility
 correctly.

 William



signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Samuli Suominen]

On 01/08/13 19:11, Luca Barbato wrote:

On 01/08/13 17:36, Michał Górny wrote:

So esystemd and ekmod now?


You know my stance on systemd, for me it is a jumble of bad and
interesting ideas not so soundly implemented, I do not have much time or
will to play with that thing.

kmod on the other hand had a pressing issue and getting it fixed-ish
took about an evening while having Federico see around it.

lu



still, first the patch goes upstream and after upstream review and 
commit to git it goes in tree
otherwise we opt to the fallback and disable udev from lvm2/cryptsetup 
when USE=static is enabled (like cryptsetup upstream suggested to me)
gentoo-specific patches mangling namespace of udev, kmod, whatever 
doesn't sound good at all

however working it with upstream sounds great

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Pacho Ramos]

El jue, 01-08-2013 a las 14:05 +0400, Sergey Popov escribió:
[...]
> Some cluster things in lvm does not work in mine setup with shared
> builds. Only USE="static static-libs" is only working combination.
> Something related with cluster file locking library - it does not load
> if it is build shared. Probably i should file bugreport about this
> 

You certainly should report it as looks like we are the only downstream
willing to still keep that option and, once upstream has dropped it and
people from other distributions won't likely help us fixing the bugs,
would be better to try to fix it (in a long term perspective)

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Pacho Ramos]

El jue, 01-08-2013 a las 18:11 +0200, Luca Barbato escribió:
> On 01/08/13 17:36, Michał Górny wrote:
> > So esystemd and ekmod now?
> 
> You know my stance on systemd, for me it is a jumble of bad and
> interesting ideas not so soundly implemented, I do not have much time or
> will to play with that thing.
> 
> kmod on the other hand had a pressing issue and getting it fixed-ish
> took about an evening while having Federico see around it.
> 
> lu
> 

But, what are the advantages of putting a lot of effort in keeping
static libs for udev? Looks like nothing really need them, and even
Debian (that doesn't use systemd by default) drops them

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Michał Górny]

Dnia 2013-08-01, o godz. 13:32:28
Rich Freeman  napisał(a):

> On Thu, Aug 1, 2013 at 11:36 AM, Michał Górny  wrote:
> > Dnia 2013-08-01, o godz. 17:17:35
> > Luca Barbato  napisał(a):
> >
> >> On 01/08/13 17:04, William Hubbs wrote:
> >> > There is a hack in our udev and kmod ebuilds that makes it possible to
> >> > build the static libraries, but I think we should remove that hack since
> >> > upstream bans building them.
> 
> Thanks for the clarification - that makes sense.
> 
> >> Anyway I volunteered Federico to sort out this mess and he got that part
> >> more or less done.
> >>
> 
> If you're willing to do the work I think the teams should be willing
> to allow you to support the necessary changes.  That is, assuming that
> the changes aren't so intrusive that they create a real potential for

If only people were that keen to fix the core issue. That is, to fix
static linking on Linux and make it useful without two batches of hacks
on top of it.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Rich Freeman]

On Thu, Aug 1, 2013 at 11:36 AM, Michał Górny  wrote:
> Dnia 2013-08-01, o godz. 17:17:35
> Luca Barbato  napisał(a):
>
>> On 01/08/13 17:04, William Hubbs wrote:
>> > There is a hack in our udev and kmod ebuilds that makes it possible to
>> > build the static libraries, but I think we should remove that hack since
>> > upstream bans building them.

Thanks for the clarification - that makes sense.

>> Anyway I volunteered Federico to sort out this mess and he got that part
>> more or less done.
>>

If you're willing to do the work I think the teams should be willing
to allow you to support the necessary changes.  That is, assuming that
the changes aren't so intrusive that they create a real potential for
bugs/etc.  You would of course have to keep up.

>
> So esystemd and ekmod now?

If the changes are really extensive then that might be the better
solution unless upstream is interested in accepting the changes.

That all assumes lu_zero wants to support all these packages.  If not
then the maintainers can drop support if they wish, and just set
deps/blockers accordingly.  If portage doesn't handle the resulting
resolution issues properly that would seem to be a portage bug - this
isn't really a typical configuration in any case.  I'd be more
concerned if it came up by default if you installed a stage3 and did
an emerge gnome.

Rich

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Luca Barbato]

On 01/08/13 17:36, Michał Górny wrote:
> So esystemd and ekmod now?

You know my stance on systemd, for me it is a jumble of bad and
interesting ideas not so soundly implemented, I do not have much time or
will to play with that thing.

kmod on the other hand had a pressing issue and getting it fixed-ish
took about an evening while having Federico see around it.

lu

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Michał Górny]

Dnia 2013-08-01, o godz. 17:17:35
Luca Barbato  napisał(a):

> On 01/08/13 17:04, William Hubbs wrote:
> > There is a hack in our udev and kmod ebuilds that makes it possible to
> > build the static libraries, but I think we should remove that hack since
> > upstream bans building them.
> 
> linking statically makes the problem apparent, I guess isn't that wise
> hiding it under a rug and hoping it won't ever bite you.
> 
> Anyway I volunteered Federico to sort out this mess and he got that part
> more or less done.
> 
> My github has his changes and I started to track what picked my attention.

So esystemd and ekmod now?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Luca Barbato]

On 01/08/13 17:04, William Hubbs wrote:
> There is a hack in our udev and kmod ebuilds that makes it possible to
> build the static libraries, but I think we should remove that hack since
> upstream bans building them.

linking statically makes the problem apparent, I guess isn't that wise
hiding it under a rug and hoping it won't ever bite you.

Anyway I volunteered Federico to sort out this mess and he got that part
more or less done.

My github has his changes and I started to track what picked my attention.

lu

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[William Hubbs]

On Thu, Aug 01, 2013 at 06:01:50AM -0400, Rich Freeman wrote:
> On Wed, Jul 31, 2013 at 11:38 PM, William Hubbs  wrote:
> > If we want to continue supporting this, it will probably require custom
> > patches to udev, and kmod. Then we will have to make sure none of that
> > breaks systemd.
> 
> Seems like the simpler solution is to just have a dep on -static
> lvm/cryptsetup for those packages.  Users who want to use static
> lvm/cryptsetup will not be able to use udev/kmod.

udev and kmod do not have any dependencies on lvm2 or cryptsetup. The
issue is that lvm2/cryptsetup[static] need the libkmod.a and libudev.a
static libraries.

There is a hack in our udev and kmod ebuilds that makes it possible to
build the static libraries, but I think we should remove that hack since
upstream bans building them.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] New eclass: db-use-r1

[Michał Górny]

> # @ECLASS_VARIABLE: DB_VERSIONS
> # @REQUIRED
> # @DESCRIPTION:
> # This variable contains a list of sys-libs/db SLOT versions the package 
> # works with. Please always sort the list so that higher slot versions come
> # first or else the package might not depend on the latest possible version of
> # sys-libs/db
> #
> # Example:
> # @CODE
> # DB_VERSIONS=( 5.0 4.8 )
> # inherit db-use-r1
> # @CODE
> #
> # Please note that you can also use bash brace expansion if you like:
> # @CODE
> # DB_VERSIONS=( 5.{3,2,1,0} 4.8 )
> # inherit db-use-r1
> # @CODE
> if ! declare -p DB_VERSIONS &>/dev/null; then
>   die "DB_VERSIONS not declared."
> fi

You may want to add here an additional check if it is an array. Otherwise,
you may end up with some random behavior when someone sets it to single
string.

> # @ECLASS-VARIABLE: DB_DEPS
> # @DESCRIPTION:
> # This eclass sets and exports DB_DEPS which should be uses as follows:
> #
> # @CODE
> # RDEPEND="${DB_DEPEND}"
> # @CODE

DB_DEPS or DB_DEPEND?

> #
> # or
> #
> # @CODE
> # RDEPEND="berkdb? ( ${DB_DEPEND} )"
> # @CODE
> DB_DEPEND=""
> if [ "${#DB_VERSIONS[@]}" -gt 1 ] ; then
>   DB_DEPEND="|| ("
> fi

I think it's perfectly valid to have '|| ( single-atom )'. IMO it's not
worth the effort to add it conditionally.

> for db_slotver in ${DB_VERSIONS[@]} ; do
>   DB_DEPEND+=" sys-libs/db:${db_slotver}"
> done

You can do it without the loop:

DB_DEPEND+=${DB_VERSIONS[@]/#/ sys-libs/db:}

> if [ "${#DB_VERSIONS[@]}" -gt 1 ] ; then
>   DB_DEPEND+=" )"
> fi
> export DB_DEPEND
> [[ ! -n ${DB_DEPEND} ]] && die "Cannot assing sys-libs/db dependency"

Looks like impossible to me. Well, unless DB_VERSIONS are empty but then
it looks like erring on the result rather than reason.

> inherit versionator multilib
> 
> # @FUNCTION: db_ver_to_slot
> # @USAGE: 
> # @DESCRIPTION:
> # Convert a version to a db slot. You need to submit at least the first two
> # Version components
> # This is meant for ebuilds using the real version number of a sys-libs/db
> # package. This eclass doesn't use it internally.
> db_ver_to_slot() {
>   if [ $# -ne 1 ]; then
>   eerror "Function db_ver_to_slot needs one argument" >&2

Shouldn't eerror use stderr on itself?

>   eerror "args given:" >&2
>   for f in $@

Missing quoting.

>   do
>   eerror " - \"$@\"" >&2
>   done
>   return 1
>   fi
>   if [ "$(get_version_component_count $1)" -lt 2 ] ; then
>   eerror "db_ver_to_slot function needs at least a version 
> component"
>   eerror "count of two."
>   return 1

'die', please.

>   fi
>   echo -n "$(get_version_component_range 1-2 $1)"

Just FYI, '-n' is not really necessary here since shell automatically
strips trailing newline in $().

> }
> 
> # @FUNCTION: db_findver
> # @USAGE: 
> # @DESCRIPTION:
> # Find the highest installed db version that fits DB_VERSIONS
> db_findver() {
>   local db_slotver
>   for db_slotver in ${DB_VERSIONS[@]} ; do
>   if has_version sys-libs/db:${db_slotver} \
>   && [ -d "/usr/include/db${db_slotver}" ] ; then

Why do you need both checks?

>   echo -n "${db_slotver}"
>   return 0
>   fi
>   done
>   return 1
> }
> 
> # @FUNCTION: db_includedir
> # @USAGE: 
> # @DESCRIPTION:
> # Get the include dir for berkeley db. This function returns the best version
> # found by db_findver()
> db_includedir() {
>   VER="$(db_findver)" || return 1

Shouldn't this be 'local'?

>   einfo "include version ${VER}" >&2

Looks more like debug-print candidate. Or, at least mention 'berkdb'
somewhere since user will have no idea 'version of what'.

>   if [ -d "/usr/include/db${VER}" ]; then
>   echo -n "/usr/include/db${VER}"
>   return 0
>   else
>   eerror "sys-libs/db package requested, but headers not found" 
> >&2
>   return 1
>   fi
> }
> 
> # @FUNCTION: db_libname
> # @USAGE: 
> # @DESCRIPTION:
> # Get the library name for berkeley db. Something like "db-4.2" will be the
> # outcome. This function returns the best version found by db_findver()
> db_libname() {
>   VER="$(db_findver)" || return 1
>   if [ -e "/usr/$(get_libdir)/libdb-${VER}.so" ]; then
>   echo -n "db-${VER}"
>   return 0
>   else
>   eerror "sys-libs/db package requested, but library not found" 
> >&2
>   return 1
>   fi
> }

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

[gentoo-dev] check-reqs* vs CFLAGS=-g

[Michał Górny]

Hello,

Since LLVM builds have grown in size lately, I wanted to add some of
check-reqs-r1 checks to it. However, I'm having real trouble guessing
what the correct sizes should be.

Most importantly, as bug #479356 points out, using '-g' greatly
increases the build size. My small measures show that without that
option, LLVM has peek build space consumption around:

- 400-550M without clang (depending on targets),
- 950-1200M with clang,
- 16G with clang & USE=debug (assertions, checks).

Those measures were done with '-O2', USE=-debug and single ABI build.
multilib build consumes almost twice as much.

But if we change the flags, for complete llvm+clang:

- 1.2G for -O2 (as shown above),
- 12G for -O0 -g.

With such a difference, I don't really see using one of the two values.
If I go for the lower one, '-g' users may still hit unexpected
out-of-space issues (like the bug shows). If I go for the higher one,
many users (including me) will unnecessarily hit the space constraints.

What can we do to improve this? I'm not really happy to have LLVM
ebuild analyze CFLAGS to set proper space constraints. Maybe we should
make check-reqs-r1 automatically bump the constraints by some
statistical multiplier when it detects -g?

[1]:https://bugs.gentoo.org/show_bug.cgi?id=479356

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Sergey Popov]

01.08.2013 01:01, Pacho Ramos пишет:
> El mié, 31-07-2013 a las 19:42 +, Robin H. Johnson escribió:
>> As both a member of base-system, and the lvm2 maintainer, I'm going to
>> go and look at fixing them, because I'd prefer to keep them available as
>> static builds.
>>
> 
> But, what is requiring it?
> https://bugs.gentoo.org/show_bug.cgi?id=478110#c33
> 
> Looks like the static stuff isn't needed (that would allow us to not
> need to keep static stuff in sys-apps/udev)
> 
>> On Wed, Jul 31, 2013 at 09:07:39PM +0200, Pacho Ramos wrote:
>>> El mar, 30-07-2013 a las 11:42 +0300, Samuli Suominen escribió:
 On 29/07/13 23:57, Pacho Ramos wrote:
> Hello
>
> As discussed at:
> https://bugs.gentoo.org/show_bug.cgi?id=478476
>
> Upstream is dropping static libs from udev and, then, sys-apps/udev is
> currently reverting that commit downstream (even if upstream says some
> problems could appear in the future as nobody is taking care of static
> stuff there).
>
> Grepping in the tree, looks like only some old genkernel versions are
> depending on it. Apart of that, what is requiring static libs in
> cryptsetup and lvm2?
>
> Thanks a lot
>

 cryptsetup upstream installed minimal Gentoo setup and tested our 
 handling of 'static' and was disappointed finding them broken

 https://bugs.gentoo.org/show_bug.cgi?id=438998 - cryptsetup static+pcre 
 fails

 https://bugs.gentoo.org/show_bug.cgi?id=468400 - cryptsetup 
 static+selinux fails

 https://bugs.gentoo.org/show_bug.cgi?id=472692 - cryptsetup static+ssl 
 fails

 https://bugs.gentoo.org/show_bug.cgi?id=462908 - lvm2 static-libs 
 missing library

 https://bugs.gentoo.org/show_bug.cgi?id=467204 - lvm2 static USE flag 
 missing proper description, yes this is minor

 https://bugs.gentoo.org/show_bug.cgi?id=370217 - lvm2 fails to build due 
 to missing -lrt, likely related to linking against libudev, yes the 
 feature we are discussing to be dropped has been completely broken for ages

 https://bugs.gentoo.org/show_bug.cgi?id=439414 - lvm2 static+selinux fails

 So we are not talking about removing anything that works, but something 
 users get hit by reading outdated guides that instruct them to enable 
 USE=static

 +1 for punting broken features


>>>
>>> We should drop that broken support I guess, but will CC its maintainers
>>> here too (they are CCed in bug report already)
>>>
>>
> 
> 
> 
> 
Some cluster things in lvm does not work in mine setup with shared
builds. Only USE="static static-libs" is only working combination.
Something related with cluster file locking library - it does not load
if it is build shared. Probably i should file bugreport about this

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Dropping static libs support from cryptsetup and lvm2

[Rich Freeman]

On Wed, Jul 31, 2013 at 11:38 PM, William Hubbs  wrote:
> If we want to continue supporting this, it will probably require custom
> patches to udev, and kmod. Then we will have to make sure none of that
> breaks systemd.

Seems like the simpler solution is to just have a dep on -static
lvm/cryptsetup for those packages.  Users who want to use static
lvm/cryptsetup will not be able to use udev/kmod.

The issue with the virtual and confusing error messages that result
seems less simple to resolve.  That sounds more like a bug in portage
though.  If I have virtual/udev[static] installed and I want to
install gnome I should just get an error indicating that to install
gnome I need to drop the static USE for virtual/udev.  Some of
portage's error messages are a bit cryptic but that shouldn't be a
reason to force a package to drop a non-default USE flag.

I'll freely admit that I could be missing some nuance here.

Rich