Gentoo Archives: gentoo-portage-dev

From: "Francesco R." <vivo75@×××××.com>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] xattr wrapper for install, bug #465000
Date: Wed, 29 Jan 2014 23:50:57
Message-Id: 52E993DB.8050600@gmail.com
In Reply to: Re: [gentoo-portage-dev] xattr wrapper for install, bug #465000 by "Anthony G. Basile"
1 Il 29/01/2014 17:33, Anthony G. Basile ha scritto:
2 > On 01/27/2014 09:02 AM, vivo75@×××××.com wrote:
3 >> On 01/26/14 23:53, Anthony G. Basile wrote:
4 >>> Hi everyone,
5 >>>
6 >>> A while back, I wrote a python wrapper for install to preserve xattrs.
7 >>> Its installed in LIBDIR/portage/bin/install.py. It is *painfully*
8 >>> slow. For a package like moodle with 16650 .php files, none of which
9 >>> probably need any xattr's set, it takes about 30 mins to install. I
10 >>> rewrote the wrapper in C. Replacing the python wrapper with the C
11 >>> wrapper, the same example reduces from about 30 mins to 2 mins.
12 >>>
13 >>> Mike and I did some back and forth about how best to write it. The
14 >>> latest version is pretty much done at
15 >>>
16 >>> https://bugs.gentoo.org/show_bug.cgi?id=465000#c56
17 >>>
18 >>> We need to get that integrated into portage. 1) I'm not 100% sure how
19 >>> to do that. 2) We may want to install it at /usr/bin/install-xattr
20 >>> because I'm sure it will be useful for more than just portage.
21 >>>
22 >>> Comments?
23 >>>
24 >> patch install from coreutils (and then upstream changes) is not an
25 >> option?
26 >> they already support selinux contexts
27 >>
28 >> anyway install-xattr could be useful and /usr/bin would be a good option
29 >> IMHO
30 >>
31 >
32 > Been there and I even had a patch ready. Upstream answer was '\0'.
33 > The only people who engaged the discussion were gentoo devs.
34 >
35 > Would patching coreutils have been the better approach? Some people
36 > might argue install and cp and mv etc should just copy contents to
37 > keep these utilities as simple as possible. Although, as you say,
38 > install can copy selinux contexts, and cp can copy xattr attributes.
39 > So what's the problem with extending installs functionality to include
40 > arbitrary xattr attributes?
41 >
42 > Anyhow, seeing as upstream is uninterested, I prefer this wrapper to
43 > maintaining a local patch against coreutils.
44 >
45 >
46 thanks for answering, so yes the wrapper seem the only sensible thing,
47 good luck, since there are no other questions in 3 days the plan must be
48 perfect ;)
49
50 on a totally unrelated and ipotetical note kde is discussing a metadata
51 engine that use xattr instead of databases, so this could become
52 important even for desktops