[gentoo-dev] Re: RFC: Changing portage's unpack behavior for non-tar files compressed with gz|Z|z|bz2|bz|lzma|xz extensions
On 07/30/2011 01:42 PM, Zac Medico wrote:
> Hi everyone,
>
> We've found that portage's unpack behavior is inconsistent for non-tar
> files compressed with gz|Z|z|bz2|bz|lzma|xz extensions [1]. Currently,
> it emulates tools like gunzip and bunzip2, unpacking them to the
> directory of the source file.
>
> For consistency, we could make it unpack them to cwd instead. PMS
> already specifies that the files should unpack to cwd, so this change
> will bring portage and PMS into agreement. Hopefully it won't break too
> many ebuilds, and we can always add compatibility code to ebuilds, like
> this:
>
>[[ ! -f ${x} ]] && { mv ${x}.gz ./ || die "mv failed"; }
>
> Is anyone opposed to making this change?
>
> [1] http://bugs.gentoo.org/show_bug.cgi?id=376741
The PMS compliant unpack behavior is implemented in
sys-apps/portage-2.1.10.10.
It's unlikely to cause any problems, if any, since the most common
practice is to unpack source files that are already in the cwd. There
were only 2 packages in all of gentoo-x86 that needed to be fixed
because they unpacked files that weren't in the cwd:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-plugins/google-talkplugin/google-talkplugin-2.1.7.0.ebuild?view=log#rev1.3
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-arcade/tuxpuck/tuxpuck-0.8.2-r1.ebuild?view=log#rev1.7
--
Thanks,
Zac
Re: [gentoo-dev] RFC: an eclass to handle optional runtime depends
On 08/02/2011 11:29 AM, Ciaran McCreesh wrote: > On Tue, 2 Aug 2011 20:18:17 +0200 > Michał Górny wrote: >>> I think I prefer the second option (copying from Exherbo). A better >>> integration with the package manager than USE flags should result >>> in a better user experience. >> >> Are you willing to update and EAPI-bump all the eclasses? May I remind >> you that most of them don't even go beyond EAPI 0? > > Most of them shouldn't need to care about EAPI at all. For those that > do, the only changes that should be necessary for an Exherbo-like > SDEPEND solution are for packages that actually want to use it... > > If you also want to switch from *DEPEND to DEPENDENCIES (which would > also allow a whole bunch of other long standing feature requests to be > fulfilled) then it's still only slightly more work -- but last time I > asked, adding new dependency classes or switching dependency syntax was > in the "too tricky to do in Portage" boat. Nowadays, it's not too tricky to do in Portage. The code that translates *DEPEND into objects can easily be extended to translate something like DEPENDENCIES into similar objects. -- Thanks, Zac
Re: [gentoo-dev] Delivery reports about your e-mail
On Wed, Aug 03, 2011 at 07:27:23AM +0200, Francisco Blas Izquierdo Riera (klondike) wrote: > El 03/08/11 06:57, Robin H. Johnson escribió: > > On Wed, Aug 03, 2011 at 04:13:19AM +0200, Francisco Blas Izquierdo Riera > > (klondike) wrote: > >> Come on they can't be serious... this won't work against Gentoo devs, > >> will it? > > It is concerning that the spammer used a valid list subscriber. > > > > Crunching all attachments for validation or moderating everything to > > catch this is a lot of work. > What about using an antispam filter reference for moderation. A properly > configured antispam system should have detected a mail like that one as, > at least, a possible virus. Sure, infra has planned similar for a long time now, but there's not enough manpower for it, mainly in the part of working out and documenting all of the last 5 years of Postfix configuration cruft so that we can port it to something else, specifically qpsmtpd for the SMTP inbound (as there are a bunch of checks specific to lists we'd like to do at SMTP time). -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] Delivery reports about your e-mail
El 03/08/11 06:57, Robin H. Johnson escribió: > On Wed, Aug 03, 2011 at 04:13:19AM +0200, Francisco Blas Izquierdo Riera > (klondike) wrote: >> Come on they can't be serious... this won't work against Gentoo devs, >> will it? > It is concerning that the spammer used a valid list subscriber. > > Crunching all attachments for validation or moderating everything to > catch this is a lot of work. What about using an antispam filter reference for moderation. A properly configured antispam system should have detected a mail like that one as, at least, a possible virus. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Delivery reports about your e-mail
On Wed, Aug 03, 2011 at 04:13:19AM +0200, Francisco Blas Izquierdo Riera (klondike) wrote: > Come on they can't be serious... this won't work against Gentoo devs, > will it? It is concerning that the spammer used a valid list subscriber. Crunching all attachments for validation or moderating everything to catch this is a lot of work. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] Delivery reports about your e-mail
El 03/08/11 03:31, c1p...@gentoo.org escribió:
> wi¹~BBº“‚ã°êØvܬ»\‡Š
> ôß(ÇW¨Ý‚é{Ò…Ä�
> ô2‡<°¼ÛûÜîÙ‹–õ–~HwX~/؉ý†íE[¬£Üœ&Ÿdd‰¶§ã±8ÒŠ6gîvs
> ã�X„òYFý5ù1çFØŸô
> L`Ce¤ÎA‘]²´e¼s§eµ©ùÍáÍmÉãZÄ&þ²cxZ:Õ•ƒÙFyÚ‘wû–a—š|×:¤b~ØüœÔ§X‰AQ¬bR\ž‡|ĉ3u±«Ÿ4æØ7‡˜øU\ö/°tÛnæ&Kß¡^¸Åڌ٤ÚbT;3ºI7%$œÎÆc™Öšoåi
> ´òÆÞ²�{jdÆŠÍ9]‰¼)ŒÒ<µ†%ùÐJžQÜU™‰PÖÈÛ93°ö´‚*{vnEÝÝtý‚ª
> ‹º9¾tÎÂ3O)ØãÇÐ GTÆP?7YF³ËŠÞÛ†W.Kë{9uè·a#¨óëð[ä:Q5cõ
> $ñï†'I(œ~B÷>0fô{íô¡iòâöÉiKYyرuÀ£:žO�«Ñ)ÒÃ5/ðJKDÒ™þ‚|ì�öóÝÀ0œQ–yPüdÏï‰ìºRg4X¨wVú«9,ëܲX‡¨�ëy(Ê«
> ÷ÀÝȪµ”OIH¨6? ’•‹)ú˜TCEò•mvƒôQ§Õ'ö)Äë _·k©Åd>Ò´fÙÏM¯Y·9õŠÝßa>[ ü×›¿ÁpØml
> –†Ž†F“Æ‚*ùêÔ_ǃEù¡Mt|>·PdéfŸž^#£Ðצ‘ NÁ
> Ã8¿º4Ë4þÍÐ]ê&6ð0ů<ÀÙÇ%é2òÔRrgg†6Û¤
> :åf˱6RÂRgýwèÉ3÷_Gbp?¾ª™vŸO÷«áþ‘-‡"8b4ýK®fŽ��
> A²Ï{ç£,"¼�8W$øª…?à6îØÒª^/U
> ^~SöEʸÅô‡µ×$;ß4>›RI_Uã·1¡åb{æ_†…:<–{Gþ}û*8Á]¼c†œ™ôãvoGµËËb�ˆ¼d�²äå
> ñÍpÅ)ÍCF—×år,G²”ÒÜbSœÁÔü9NöÒ³!^.ÎÙ>8~è�c)N«`CN“ýΑ%\ Œƒ£®
> Û3¨a$Ú9è•Í T±¬�vàÝfíH}ýˆY˜[Å°a›ö‘8f
> oÇÈf©ïB>eÏ—vgPþùøתd�2„}U?׊)°Š“ÏÐ&œR·†±¥Å"
> ®µÍ©#{Ç¥¨!-,Ö•�WkL7-¬/Ä5˜Dw75´Å^�úšÀ�D æbyÅs/«†SÃF£SŸØÂ`kãB{Û
> ÷í—oO\øC¼µÅUö/ÙKÙ�²Ž%hðÏý%Úó‚°�à,ÓúNnŒ;‚«hAtžé¡PÒYRó¨œ{
>
Come on they can't be serious... this won't work against Gentoo devs,
will it?
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: POSIX capability in Gentoo
Arfrever Frehtes Taifersar Arahesis posted on Tue, 02 Aug 2011 22:46:54 +0200 as excerpted: > 2011-08-02 19:39:18 Ciaran McCreesh napisał(a): >> On Tue, 02 Aug 2011 13:36:12 -0400 Jonathan Callen >> wrote: >> > That statement needs one more qualification: "and doesn't use >> > portage". Portage will (by default) remove files on uninstall even if >> > they *do not* match the checksum recorded in the vdb. This implies >> > that most people will *not* see any issues due to something other >> > than the package manager modifying the files behind the package >> > manager's back. >> >> Ugh, seriously? When did that happen? > > http://git.overlays.gentoo.org/gitweb/?p=proj/ portage.git;a=commit;h=a133cb89d5279df7febcd0c8ab3890e2ccfb897a > >> Maybe we need to spec VDB after all to avoid that kind of nonsense. > > I think that unmerge-orphans is a useful feature. Indeed. FEATURES=unmerge-orphans is optional which is good, but I'm glad it's there. I've no idea what the default is as I've had that on ever since I saw the changelog entry where it was introduced. That'd likely explain why I never had problems with lafilefixer tho. I'd guess the unmerge-orphans feature and lafilefixer appeared about the same time, at least for ~arch. Of course, I have FEATURES=fixlafiles set too, so it'd be handled by portage automatically now if I didn't have (PKG_)INSTALL_MASK="*.la" killing them but for libtool itself. -- 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: POSIX capability in Gentoo
On Tue, Aug 02, 2011 at 06:39:18PM +0100, Ciaran McCreesh wrote: > On Tue, 02 Aug 2011 13:36:12 -0400 > Jonathan Callen wrote: > > That statement needs one more qualification: "and doesn't use > > portage". Portage will (by default) remove files on uninstall even if > > they *do not* match the checksum recorded in the vdb. This implies > > that most people will *not* see any issues due to something other > > than the package manager modifying the files behind the package > > manager's back. > > Ugh, seriously? When did that happen? That's a massive change to how > VDB is supposed to work. That's been in place a long while; pkgcore has done it from day one also. That's not a "massive change" to vdb behaviour either; file collisions aren't supposed to occur, as such ownership of the file is basically guranteed back to a single package. Throw in CONFIG_PROTECT for adjusting the behaviour, and you have a far more preferable norm than "lets just leave a shit ton of .pyc/.pyo on the fs". Moving on... ~brian
Re: [gentoo-dev] Re: POSIX capability in Gentoo
2011-08-02 19:39:18 Ciaran McCreesh napisał(a): > On Tue, 02 Aug 2011 13:36:12 -0400 > Jonathan Callen wrote: > > That statement needs one more qualification: "and doesn't use > > portage". Portage will (by default) remove files on uninstall even if > > they *do not* match the checksum recorded in the vdb. This implies > > that most people will *not* see any issues due to something other > > than the package manager modifying the files behind the package > > manager's back. > > Ugh, seriously? When did that happen? http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=a133cb89d5279df7febcd0c8ab3890e2ccfb897a > Maybe we need to spec VDB after all to avoid that kind of nonsense. I think that unmerge-orphans is a useful feature. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: virtual/icon-theme
On Tue, Aug 2, 2011 at 21:48, "Paweł Hajdan, Jr." wrote: > On 8/2/11 11:20 AM, Markos Chandras wrote: >> I would like to discuss the possibility to create a new virtual package >> for all the icon-theme packages. According to this bug[1], it seems like >> pcmanfm, and possible other applications too, require an icon-theme to >> be present, no matter which one. So I think it would make sense to >> create a new virtual package to include all the existing icon-themes. > > www-client/chromium isn't going to take this train. I was thinking about > something similar a few months ago but it turned out to be more complex > (the icon set used depends on the running desktop environment). > > Anyway, if it's useful for other packages sounds good to me. When running a DE you usually have an icon set lying around, the problem usually shows up when you run a simple WM with random apps on top. -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com
Re: [gentoo-dev] RFC: virtual/icon-theme
On 8/2/11 11:20 AM, Markos Chandras wrote: > I would like to discuss the possibility to create a new virtual package > for all the icon-theme packages. According to this bug[1], it seems like > pcmanfm, and possible other applications too, require an icon-theme to > be present, no matter which one. So I think it would make sense to > create a new virtual package to include all the existing icon-themes. www-client/chromium isn't going to take this train. I was thinking about something similar a few months ago but it turned out to be more complex (the icon set used depends on the running desktop environment). Anyway, if it's useful for other packages sounds good to me. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: an eclass to handle optional runtime depends
On 8/2/11 11:18 AM, Michał Górny wrote: >> I think I prefer the second option (copying from Exherbo). A better >> integration with the package manager than USE flags should result in a >> better user experience. > > Are you willing to update and EAPI-bump all the eclasses? May I remind > you that most of them don't even go beyond EAPI 0? Why all of them? We don't necessarily need this now, I can wait. By the way, maybe that's a good point to just do a postinst-based implementation for now, that would just check whether the recommended/suggested packages are installed. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: virtual/icon-theme
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/02/2011 07:30 PM, Chí-Thanh Christopher Nguyễn wrote: > Markos Chandras schrieb: >> - --: Not all packages include the same icons so users may end up with >> missing icons for some applications. However, most icon themes should >> include all the basic icons. > > You could have USE flags for the virtual, so that some package could > depend on virtual/icon-theme[foo-icons], while the virtual depends on > foo-icons? ( || ( list of packages known to contain foo-icons ) ) > > Of course, this makes sense only if it is known or easy to find out > which icon-themes contain which icons. > > > Best regards, > Chí-Thanh Christopher Nguyễn > > Don't you think that this is a bit overkill? Do you think that having IUSE="ipod k3b quassel skype" is better than having no use flags at all? I personally dislike the idea since most icon themes ( oxygen, gnome, lxde, faenza, xfce(?) ) provide pretty much the same icons. - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJOOEV3AAoJEPqDWhW0r/LCXqgP/2QqZ2f12CuR5xT4ZtICDFcv vGNmxhtL7+HvLTIY3brMvlY8hj8U1iExAtWq5pXpwBLjLpClgQTwbtXut6iOKYNG JTYTtLA/WDfIFwiPzYs9yeDvZQgRgnyRfN5mRQ75pQlc1HYFy1pq2Tciq/Am7QeC 8KWNbmUfEJHLpadhiRxMD1XU6qQOnnhH5E+AvlKtvTvxUrf/1Ux+VdO47f7QjhPD AIkpF6ZFpmaeCRxTZSzQ1qOphTRq0AHi82mg5SRsGmIkj5LssypguCuBrZx73hll Wzh7JFHqouKM3jG2Gp/bi32U9xo6hfCpe+FQoJjf/5rwZsoNdw2BHYg9O2Itj2Pd fqCw4B7qV1e/aXzmaEcZwjL9/G7ySdQkoC7MbO1NH1AwQkFlNtWgQrP8gOITskFE 6Z2aWaZHEZKh90EUqb01v/wV+Q/WLZTpz3cLxzq3NIWl7jcK+vU04ZnQf0QMQPUe 3R7Pp7oxI7edHmrVMnLhNkoU0Do3+nA+4Q8hNiEpPg+XM6VHOp+k/nLb/HS10txE goSXpbEwWnrjgcNnsFuvkitlKeT+Yy5bww+8M9OgW1Fa/T77AGsccXKTaSDXmTjv 0n3QDG7iwzqtos7GqBNAJxuSjGtyQjnM7nHggD2pXN9F1uZWmOuiP70UB69NXcrW hTzaR99RJhsAH5Gtdim8 =vkLs -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: virtual/icon-theme
On 08/02/2011 09:20 PM, Markos Chandras wrote: > Hello fellow developers, > > I would like to discuss the possibility to create a new virtual package > for all the icon-theme packages. According to this bug[1], it seems like > pcmanfm, and possible other applications too, require an icon-theme to > be present, no matter which one. So I think it would make sense to > create a new virtual package to include all the existing icon-themes. > > ++: Avoid ugly dependencies like || ( x11-themes/foo-icon-theme > x11-themes/bar-icon-theme ... ) > > --: Not all packages include the same icons so users may end up with > missing icons for some applications. However, most icon themes should > include all the basic icons. > > [1] https://bugs.gentoo.org/show_bug.cgi?id=376309 > > Thoughts? > since whatever gets added to the virtual should be at least almost up to date with the spec, and provide the most common icons virtual/freedesktop-icon-theme for name, just my opinion... http://standards.freedesktop.org/ as HOMEPAGE freedesktop-b...@gentoo.org as maintainer
Re: [gentoo-dev] RFC: an eclass to handle optional runtime depends
On Tue, Aug 2, 2011 at 21:18, Michał Górny wrote: > On Tue, 02 Aug 2011 10:58:56 -0700 > ""Paweł Hajdan, Jr."" wrote: > >> On 8/2/11 12:35 AM, Michał Górny wrote: >> > On Sun, 31 Jul 2011 10:19:03 -0700 >> > ""Paweł Hajdan, Jr."" wrote: >> >> I'm interested in some sort of suggested/recommend deps for >> >> www-client/chromium, but I'm not sure if eclass is the right >> >> implementation. >> > I don't think we can start drafting until we agree on one solution. >> > AFAICS there are two major ideas: >> > 1) using special USEflags for that (which I can draft if you like), >> > 2) copying DEPENDENCIES syntax from exherbo. I guess there's nothing >> > special to draft here, only to decide on how much to copy. >> > >> > First gives you compat and handles all the cases, second one either >> > doesn't handle everything or forces a completely new syntax. >> >> I think I prefer the second option (copying from Exherbo). A better >> integration with the package manager than USE flags should result in a >> better user experience. > > Are you willing to update and EAPI-bump all the eclasses? May I remind > you that most of them don't even go beyond EAPI 0? That should be a reason to aggressively push eclass EAPI updates, not hold back on new features :) > -- > Best regards, > Michał Górny > -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com
Re: [gentoo-dev] RFC: an eclass to handle optional runtime depends
On Tue, 2 Aug 2011 20:18:17 +0200 Michał Górny wrote: > > I think I prefer the second option (copying from Exherbo). A better > > integration with the package manager than USE flags should result > > in a better user experience. > > Are you willing to update and EAPI-bump all the eclasses? May I remind > you that most of them don't even go beyond EAPI 0? Most of them shouldn't need to care about EAPI at all. For those that do, the only changes that should be necessary for an Exherbo-like SDEPEND solution are for packages that actually want to use it... If you also want to switch from *DEPEND to DEPENDENCIES (which would also allow a whole bunch of other long standing feature requests to be fulfilled) then it's still only slightly more work -- but last time I asked, adding new dependency classes or switching dependency syntax was in the "too tricky to do in Portage" boat. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: virtual/icon-theme
On Tue, Aug 2, 2011 at 21:20, Markos Chandras wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hello fellow developers, > > I would like to discuss the possibility to create a new virtual package > for all the icon-theme packages. According to this bug[1], it seems like > pcmanfm, and possible other applications too, require an icon-theme to > be present, no matter which one. So I think it would make sense to > create a new virtual package to include all the existing icon-themes. > > ++: Avoid ugly dependencies like || ( x11-themes/foo-icon-theme > x11-themes/bar-icon-theme ... ) > > - --: Not all packages include the same icons so users may end up with > missing icons for some applications. However, most icon themes should > include all the basic icons. > > [1] https://bugs.gentoo.org/show_bug.cgi?id=376309 > > Thoughts? I like the idea, anything that makes things work out of the box without sacrificing options is welcome :) > - -- > Regards, > Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.17 (GNU/Linux) > > iQIcBAEBCgAGBQJOOD/0AAoJEPqDWhW0r/LCF84P/jlZqs2+KLszt7aHq43pGa56 > AddR+cBI0qBxrB5/eNSI71Mkn3+WPIyqEzZTfo6BUIm3GsC9u1kx7tNQM5wgri41 > YDZVZlUjD533slR6lOI6/INE6bQZ6y7bfl3pDLh9SMk2qKxMkww21+joeKZdgzqX > iq3TNOXtbwlL1DlpBYYMWuCLctw82+HQcx6h5ISDqBPoh6RHiOa8pjWgDaFEzzsR > ZCWwDjteSFEkKZOcvFONkcrq7Ntu2K5o+tBSAXQ2wT9bPuV9TPRYhNbmVoOodrMz > VYF7i2g4cYBmdikqsDZ2V6Amgt5dbyYSk8q9Fi2jYxQAj3CMGKFUZlsnJL+opluO > f6qj/7b2Z44vDulRWZHCzqy07JV3fnyP23LQi8QKGyKCmvbNAE3+jFSr+eyiaCgF > QSzn9oCyj7RkuUVJ/n15L7NRbCtx+sBFUBJ8oy19jK/pz1T3ac8c2FiovyhsW3Ml > Z5Q5zmmWTIQaCkIn8jUPBQ5sQRh9BNJNLOjTkBEKWxgM0GHMYJUadWJ3zCoxlUXh > pQ8arnTSU1Ascfd7otmJZVh6SPQNBCXmwWrKldssEW9oV/l+am6Js2DERsEC6fPq > RZISLt1wgmqpAdtKlYytgc+cBcHhfh8e+IWV6tgw0oEICwQEW5d7z7kDwxddv8oK > ZMLCxEH/TKvV90nMxxeG > =GIKP > -END PGP SIGNATURE- > > -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com
Re: [gentoo-dev] RFC: virtual/icon-theme
Markos Chandras schrieb: - --: Not all packages include the same icons so users may end up with missing icons for some applications. However, most icon themes should include all the basic icons. You could have USE flags for the virtual, so that some package could depend on virtual/icon-theme[foo-icons], while the virtual depends on foo-icons? ( || ( list of packages known to contain foo-icons ) ) Of course, this makes sense only if it is known or easy to find out which icon-themes contain which icons. Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] RFC: virtual/icon-theme
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello fellow developers, I would like to discuss the possibility to create a new virtual package for all the icon-theme packages. According to this bug[1], it seems like pcmanfm, and possible other applications too, require an icon-theme to be present, no matter which one. So I think it would make sense to create a new virtual package to include all the existing icon-themes. ++: Avoid ugly dependencies like || ( x11-themes/foo-icon-theme x11-themes/bar-icon-theme ... ) - --: Not all packages include the same icons so users may end up with missing icons for some applications. However, most icon themes should include all the basic icons. [1] https://bugs.gentoo.org/show_bug.cgi?id=376309 Thoughts? - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJOOD/0AAoJEPqDWhW0r/LCF84P/jlZqs2+KLszt7aHq43pGa56 AddR+cBI0qBxrB5/eNSI71Mkn3+WPIyqEzZTfo6BUIm3GsC9u1kx7tNQM5wgri41 YDZVZlUjD533slR6lOI6/INE6bQZ6y7bfl3pDLh9SMk2qKxMkww21+joeKZdgzqX iq3TNOXtbwlL1DlpBYYMWuCLctw82+HQcx6h5ISDqBPoh6RHiOa8pjWgDaFEzzsR ZCWwDjteSFEkKZOcvFONkcrq7Ntu2K5o+tBSAXQ2wT9bPuV9TPRYhNbmVoOodrMz VYF7i2g4cYBmdikqsDZ2V6Amgt5dbyYSk8q9Fi2jYxQAj3CMGKFUZlsnJL+opluO f6qj/7b2Z44vDulRWZHCzqy07JV3fnyP23LQi8QKGyKCmvbNAE3+jFSr+eyiaCgF QSzn9oCyj7RkuUVJ/n15L7NRbCtx+sBFUBJ8oy19jK/pz1T3ac8c2FiovyhsW3Ml Z5Q5zmmWTIQaCkIn8jUPBQ5sQRh9BNJNLOjTkBEKWxgM0GHMYJUadWJ3zCoxlUXh pQ8arnTSU1Ascfd7otmJZVh6SPQNBCXmwWrKldssEW9oV/l+am6Js2DERsEC6fPq RZISLt1wgmqpAdtKlYytgc+cBcHhfh8e+IWV6tgw0oEICwQEW5d7z7kDwxddv8oK ZMLCxEH/TKvV90nMxxeG =GIKP -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: an eclass to handle optional runtime depends
On Tue, 02 Aug 2011 10:58:56 -0700 ""Paweł Hajdan, Jr."" wrote: > On 8/2/11 12:35 AM, Michał Górny wrote: > > On Sun, 31 Jul 2011 10:19:03 -0700 > > ""Paweł Hajdan, Jr."" wrote: > >> I'm interested in some sort of suggested/recommend deps for > >> www-client/chromium, but I'm not sure if eclass is the right > >> implementation. > > I don't think we can start drafting until we agree on one solution. > > AFAICS there are two major ideas: > > 1) using special USEflags for that (which I can draft if you like), > > 2) copying DEPENDENCIES syntax from exherbo. I guess there's nothing > >special to draft here, only to decide on how much to copy. > > > > First gives you compat and handles all the cases, second one either > > doesn't handle everything or forces a completely new syntax. > > I think I prefer the second option (copying from Exherbo). A better > integration with the package manager than USE flags should result in a > better user experience. Are you willing to update and EAPI-bump all the eclasses? May I remind you that most of them don't even go beyond EAPI 0? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: an eclass to handle optional runtime depends
On 8/2/11 12:35 AM, Michał Górny wrote: > On Sun, 31 Jul 2011 10:19:03 -0700 > ""Paweł Hajdan, Jr."" wrote: >> I'm interested in some sort of suggested/recommend deps for >> www-client/chromium, but I'm not sure if eclass is the right >> implementation. > I don't think we can start drafting until we agree on one solution. > AFAICS there are two major ideas: > 1) using special USEflags for that (which I can draft if you like), > 2) copying DEPENDENCIES syntax from exherbo. I guess there's nothing >special to draft here, only to decide on how much to copy. > > First gives you compat and handles all the cases, second one either > doesn't handle everything or forces a completely new syntax. I think I prefer the second option (copying from Exherbo). A better integration with the package manager than USE flags should result in a better user experience. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: POSIX capability in Gentoo
On Tue, 02 Aug 2011 13:36:12 -0400 Jonathan Callen wrote: > That statement needs one more qualification: "and doesn't use > portage". Portage will (by default) remove files on uninstall even if > they *do not* match the checksum recorded in the vdb. This implies > that most people will *not* see any issues due to something other > than the package manager modifying the files behind the package > manager's back. Ugh, seriously? When did that happen? That's a massive change to how VDB is supposed to work. Maybe we need to spec VDB after all to avoid that kind of nonsense. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: POSIX capability in Gentoo
Ciaran McCreesh wrote: > On Tue, 2 Aug 2011 17:11:28 + (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: >> Ciaran McCreesh posted on Tue, 02 Aug 2011 16:05:54 +0100 as >> excerpted: >> > Because going behind the package mangler's back results in horribly >> > screwed up systems (as anyone who's ever used lafilefixer will tell >> > you...). >> >> Well, not "anyone". I never had any problems with it. > > You did, you just didn't notice it. You'll find out sooner or later > when you get bitten by one of the will-never-be-uninstalled-now .la > files that it modified on your system without updating VDB. > >> (Observation: Unqualified any/all statements are rather like >> greedy .* regex handling, sometimes they include more than one might >> intend!) > > Well, if you prefer, "anyone who's ever used lafilefixer and then either > looked carefully at what happened or got hit by random nastiness later > on". > That statement needs one more qualification: "and doesn't use portage". Portage will (by default) remove files on uninstall even if they *do not* match the checksum recorded in the vdb. This implies that most people will *not* see any issues due to something other than the package manager modifying the files behind the package manager's back. -- Jonathan Callen
Re: [gentoo-dev] Re: POSIX capability in Gentoo
On Tue, 2 Aug 2011 17:11:28 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > Ciaran McCreesh posted on Tue, 02 Aug 2011 16:05:54 +0100 as > excerpted: > > Because going behind the package mangler's back results in horribly > > screwed up systems (as anyone who's ever used lafilefixer will tell > > you...). > > Well, not "anyone". I never had any problems with it. You did, you just didn't notice it. You'll find out sooner or later when you get bitten by one of the will-never-be-uninstalled-now .la files that it modified on your system without updating VDB. > (Observation: Unqualified any/all statements are rather like > greedy .* regex handling, sometimes they include more than one might > intend!) Well, if you prefer, "anyone who's ever used lafilefixer and then either looked carefully at what happened or got hit by random nastiness later on". -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: POSIX capability in Gentoo
Ciaran McCreesh posted on Tue, 02 Aug 2011 16:05:54 +0100 as excerpted: > Because going behind the package mangler's back results in horribly > screwed up systems (as anyone who's ever used lafilefixer will tell > you...). Well, not "anyone". I never had any problems with it. (YMMV, but soon enough, I switched to an installmask with an exception for libtool, then rebuilt the system. No *.la file worries since! =:^) (Observation: Unqualified any/all statements are rather like greedy .* regex handling, sometimes they include more than one might intend!) -- 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] POSIX capability in Gentoo
On Tue, 02 Aug 2011 11:19:21 -0400 "Anthony G. Basile" wrote: > Is rlpkg going behind the PM's back when it does selinux labelings? Yup. Also, note that PMS has wording for selinux. > I know there are difference, but if there's a screwup in some policy, it > also leads to horribly screwed up system. Nonetheless, I'm not > insensitive to what you are saying, and I think the safer approach > would be to write a howto and show the user how to manually convert > some typical binaries. There are only a handful that would be > targeted. Why are caps so important that we should be encouraging users to subvert things, yet at the same time not important enough that they should be handled properly? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] POSIX capability in Gentoo
On 08/02/2011 11:05 AM, Ciaran McCreesh wrote: >>> Please don't. >> > >> > Why would this be bad? > Because going behind the package mangler's back results in horribly > screwed up systems (as anyone who's ever used lafilefixer will tell > you...). Is rlpkg going behind the PM's back when it does selinux labelings? I know there are difference, but if there's a screwup in some policy, it also leads to horribly screwed up system. Nonetheless, I'm not insensitive to what you are saying, and I think the safer approach would be to write a howto and show the user how to manually convert some typical binaries. There are only a handful that would be targeted. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 GnuPG ID : D0455535
Re: [gentoo-dev] POSIX capability in Gentoo
On Tue, Aug 2, 2011 at 11:05 AM, Anthony G. Basile wrote: > On 08/02/2011 10:54 AM, Ciaran McCreesh wrote: >>> > I was thinking something even dirtier, something outside of the PMS >>> > altogether, along the lines of what one does when converting to a >>> > selinux system where one relabels the entire filesystem with rlpkg. >>> > So no, not something via pkg_postinst(). >> Please don't. > Why would this be bad? Something that comes to mind would be the inability to systematically verify the installed system. We obviously don't currently store posix capabilities the way we store mtimes and hashes, but I would think that this would just be one more part of the EAPI if we properly define it. That said, I don't see manual scripts outside of portage being a possible workaround, but it should probably only be used experimentally. Rich
Re: [gentoo-dev] POSIX capability in Gentoo
On Tue, 02 Aug 2011 11:05:34 -0400 "Anthony G. Basile" wrote: > On 08/02/2011 10:54 AM, Ciaran McCreesh wrote: > >> > I was thinking something even dirtier, something outside of the > >> > PMS altogether, along the lines of what one does when converting > >> > to a selinux system where one relabels the entire filesystem > >> > with rlpkg. So no, not something via pkg_postinst(). > > > Please don't. > > Why would this be bad? Because going behind the package mangler's back results in horribly screwed up systems (as anyone who's ever used lafilefixer will tell you...). This is something worth solving properly, and because of all the damage it can cause if done badly, it's worth not doing at all until a proper solution is available. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] POSIX capability in Gentoo
On Tue, 02 Aug 2011 10:51:22 -0400 "Anthony G. Basile" wrote: > On 08/02/2011 10:31 AM, Ciaran McCreesh wrote: > > On Tue, 02 Aug 2011 10:28:58 -0400 > > "Anthony G. Basile" wrote: > >> I prefer capsetting in the PMS itself, with a nice clean function > >> which auto detects all the necessary conditions and transparently > >> preserves caps, as you suggest. Maybe this can be in EAPI=5. > > Would need a spec, along with a way of dealing with all the > > problems: what happens if the build fs supports caps but the > > install fs doesn't? What about if caps are supported on both but in > > different ways (tmpfs on some kernels)? Is it up to the PM to deal > > with that? How does the PM even know? > > > > That's exactly what I was thinking of for the PM. It would have to > autodetect all that. Eg. it could create a test file on each fs and > then do a getcap on it and if it fails, you have your answer. If > necessary and it exists, it could look at /proc/config. I think it's > doable. Just let the capsetting function store all details internally when called. I don't think it's really important whether build fs capsetting succeeds. So, it's like: 1) capset on buildfs, store details internally; 2) move to livefs; 3) [optionally] getcap on livefs, done if set; 4) capset on livefs; 5) getcap on livefs, done if set; 6) fallback to set?id (using info from stored capsetting function call) if necessary. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] POSIX capability in Gentoo
On 08/02/2011 10:54 AM, Ciaran McCreesh wrote: >> > I was thinking something even dirtier, something outside of the PMS >> > altogether, along the lines of what one does when converting to a >> > selinux system where one relabels the entire filesystem with rlpkg. >> > So no, not something via pkg_postinst(). > Please don't. > Why would this be bad? -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 GnuPG ID : D0455535
Re: [gentoo-dev] POSIX capability in Gentoo
On Tue, 02 Aug 2011 10:51:22 -0400 "Anthony G. Basile" wrote: > > Would need a spec, along with a way of dealing with all the > > problems: what happens if the build fs supports caps but the > > install fs doesn't? What about if caps are supported on both but in > > different ways (tmpfs on some kernels)? Is it up to the PM to deal > > with that? How does the PM even know? > > That's exactly what I was thinking of for the PM. It would have to > autodetect all that. That's the problematic part... It's not quite "the PM just needs to come up with a cure for cancer", but it's decidedly non-trivial. > Eg. it could create a test file on each fs and > then do a getcap on it and if it fails, you have your answer. But it can and will be merging to multiple filesystems, some of which support caps and some of which don't. Maybe the answer is to have the PM do the merge, including caps, and if it detects that the caps setting failed then it should fall back to some kind of set*id bit (but which one?). But I'm not sure that setting caps that won't actually work will necessarily give a failure. Another possibility is to simply require that the PM preserve caps from the build fs to the root fs, and if it fails, to abort horribly (except we hate dying mid-merge, since it's impossible to clean up). Then it's the user's responsibility to turn off caps on their build fs if necessary. But neither of those are anywhere close to implementable without a lot of careful thought and planning... We need to *prove* that we're safe here, not guess that we're probably ok based upon a bit of testing. And we haven't even started talking about binaries yet... > I was thinking something even dirtier, something outside of the PMS > altogether, along the lines of what one does when converting to a > selinux system where one relabels the entire filesystem with rlpkg. > So no, not something via pkg_postinst(). Please don't. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] POSIX capability in Gentoo
On 08/02/2011 10:31 AM, Ciaran McCreesh wrote: > On Tue, 02 Aug 2011 10:28:58 -0400 > "Anthony G. Basile" wrote: >> I prefer capsetting in the PMS itself, with a nice clean function >> which auto detects all the necessary conditions and transparently >> preserves caps, as you suggest. Maybe this can be in EAPI=5. > Would need a spec, along with a way of dealing with all the problems: > what happens if the build fs supports caps but the install fs doesn't? > What about if caps are supported on both but in different ways (tmpfs > on some kernels)? Is it up to the PM to deal with that? How does the PM > even know? > That's exactly what I was thinking of for the PM. It would have to autodetect all that. Eg. it could create a test file on each fs and then do a getcap on it and if it fails, you have your answer. If necessary and it exists, it could look at /proc/config. I think it's doable. >> I'm also wondering if, in the mean time, it might be worth writing a >> bash script and/or howto on converting as many binaries as possible >> from setuid to caps --- hitting up all the usual suspects. Its not >> ideal but might still be useful until we get this squarely in the PMS. > PMS currently explicitly states that caps might get clobbered on a > merge (because Portage does that sometimes). So if you're doing it now, > it'd have to be as a pkg_postinst thing. But I'd strongly recommend not > going that route, since it'll almost certainly go horribly wrong in a > "your system randomly no longer works" kind of way... Better to ban > things from using caps for now. > I was thinking something even dirtier, something outside of the PMS altogether, along the lines of what one does when converting to a selinux system where one relabels the entire filesystem with rlpkg. So no, not something via pkg_postinst(). -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 GnuPG ID : D0455535
Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?
On Tue, Aug 2, 2011 at 4:02 AM, Michał Górny wrote: > BTW doesn't encrypting rootfs require initramfs anyway? > Yup. On a side note. I've been experimenting with Dracut+LVM+RAID5 and have found that it actually works pretty transparently. Now, I haven't tried it with /usr not on the rootfs - I can tell that Dracut is definitely parsing my /etc/fstab to mount my root, but I'm not sure if it tries to mount anything else by default. It is fairly slick - it mounts root any way it can read-only to get to the fstab, and then remounts it following the options in fstab. (Which means that you need to make sure fstab is accurate since it actually gets used for the rootfs now.) I also found that the dracut initramfs is MUCH faster than the genkernel one - it does a good job of only loading drivers necessary to find the root, and it can take hints to speed that up. It also required less configuration - the only required kernel parameter even for mdadm+lvm is root= (which takes device, UUID, or label). I got it working with an old-metadata /boot (probably need to mess with grub v2 to avoid that, assuming that even works), and then everything else including root on mdadm-raid5+LVM. So, my feeling is that while we should support minimal (ie non-gnome/etc) configurations that follow FHS and don't require an initramfs, I don't really see leveraging dracut as a big problem as long as we update our documentation to make the preferred approach clear. Everybody should also read that Fedora link earlier in the thread: http://fedoraproject.org/wiki/Features/UsrMove I'm not suggesting that we should do this, but this does seem like a legitimate use-case. It is a bit more suited to binary distros with release cycles, but I could see in a datacenter how it might be nice to NFS-mount just about everything including /usr, /bin, /lib, etc. Such a setup would actually be pretty easy to accomplish with Gentoo - in theory you can just create symlinks for the various root directories into /usr and let the package manager install the files into them. In practice it might run into issues (I know that symlinks for some of the top-level directories were not liked by some of the package managers in the past - I had to use bind mounts to accomplish this, and that might be a better solution though I have no idea if Dracut can figure that out in fstab). Rich
Re: [gentoo-dev] POSIX capability in Gentoo
On Tue, 02 Aug 2011 10:28:58 -0400 "Anthony G. Basile" wrote: > I prefer capsetting in the PMS itself, with a nice clean function > which auto detects all the necessary conditions and transparently > preserves caps, as you suggest. Maybe this can be in EAPI=5. Would need a spec, along with a way of dealing with all the problems: what happens if the build fs supports caps but the install fs doesn't? What about if caps are supported on both but in different ways (tmpfs on some kernels)? Is it up to the PM to deal with that? How does the PM even know? > I'm also wondering if, in the mean time, it might be worth writing a > bash script and/or howto on converting as many binaries as possible > from setuid to caps --- hitting up all the usual suspects. Its not > ideal but might still be useful until we get this squarely in the PMS. PMS currently explicitly states that caps might get clobbered on a merge (because Portage does that sometimes). So if you're doing it now, it'd have to be as a pkg_postinst thing. But I'd strongly recommend not going that route, since it'll almost certainly go horribly wrong in a "your system randomly no longer works" kind of way... Better to ban things from using caps for now. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] POSIX capability in Gentoo
On 08/02/2011 03:08 AM, Michał Górny wrote: > On Sun, 31 Jul 2011 16:00:40 -0400 > "Anthony G. Basile" wrote: > >> On 07/31/2011 03:46 PM, Nirbheek Chauhan wrote: >>> On Sun, Jul 31, 2011 at 8:13 PM, Anthony G. Basile >>> wrote: Hi everyone, A couple of days ago, bonsaikitten (Patrick), kerframil (Kerin Millar) and myself were talking about other distros moving away from setuid binaries towards caps. Openwall and Fedora are now setuid-less [1]. Some googling showed that Constanze has done quite a bit of work in the area and that there was a consensus to include functions to set caps within portage [2]. I don't know what, if anything has been done since then, but I'd like to lend my support. >>> One problem that came up was that a lot of people use tmpfs for >>> /var/tmp/portage, and tmpfs doesn't support xattrs which are needed >>> for setting caps. >>> >>> Linux 3.0 has added support for xattrs with tmpfs (the redhat folks >>> did the work, afaik), so that problem is partly solved now. >> >> I know, there are lots of places where xattrs is not supported that >> lead to the same problem. I'm tempted to respond with pkg_postinst() >> but I see QA problems written all over that. > > We can either do that or 'Future EAPI' capsetting in PMS. Then, a PM > could implement capsetting functions in a such way that they will > preserve caps internally to PM and re-set them when merging to livefs. > I prefer capsetting in the PMS itself, with a nice clean function which auto detects all the necessary conditions and transparently preserves caps, as you suggest. Maybe this can be in EAPI=5. I'm also wondering if, in the mean time, it might be worth writing a bash script and/or howto on converting as many binaries as possible from setuid to caps --- hitting up all the usual suspects. Its not ideal but might still be useful until we get this squarely in the PMS. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 GnuPG ID : D0455535
Re: [gentoo-dev] RFC: an eclass to handle optional runtime depends
On Tue, 2 Aug 2011 09:35:05 +0200 Michał Górny wrote: > I don't think we can start drafting until we agree on one solution. > AFAICS there are two major ideas: > 1) using special USEflags for that (which I can draft if you like), > 2) copying DEPENDENCIES syntax from exherbo. I guess there's nothing >special to draft here, only to decide on how much to copy. > > First gives you compat and handles all the cases, second one either > doesn't handle everything or forces a completely new syntax. As well as drafting it, you should produce a test implementation and try out a whole bunch of packages by using it. The last time a big user visible UI related feature like this ended up in PMS without a prior implementation, it ended up having several fairly nasty problems... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?
On Sat, 30 Jul 2011 16:28:54 +0200 Chí-Thanh Christopher Nguyễn wrote: > Samuli Suominen schrieb: > > > > Someone mentioned NFS mount on /usr. Do we have other reasons? How > > many users that might be? > > If you have / encrypted, then you can leave /usr unencrypted as it > contains no secrets. Also /usr can remain mounted read-only most of > the time, so there is a reduced chance of accidental corruption. > I don't know the number of users who might want this, and I imagine it > is difficult to count them. BTW doesn't encrypting rootfs require initramfs anyway? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: an eclass to handle optional runtime depends
On Sun, 31 Jul 2011 10:19:03 -0700 ""Paweł Hajdan, Jr."" wrote: > I'm interested in some sort of suggested/recommend deps for > www-client/chromium, but I'm not sure if eclass is the right > implementation. > > I think I agree with Ciaran that this should be implemented as a PMS > update. Let me know if I can help with drafting a change proposal or > something like that. I don't think we can start drafting until we agree on one solution. AFAICS there are two major ideas: 1) using special USEflags for that (which I can draft if you like), 2) copying DEPENDENCIES syntax from exherbo. I guess there's nothing special to draft here, only to decide on how much to copy. First gives you compat and handles all the cases, second one either doesn't handle everything or forces a completely new syntax. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] POSIX capability in Gentoo
On Sun, 31 Jul 2011 16:00:40 -0400 "Anthony G. Basile" wrote: > On 07/31/2011 03:46 PM, Nirbheek Chauhan wrote: > > On Sun, Jul 31, 2011 at 8:13 PM, Anthony G. Basile > > wrote: > >> Hi everyone, > >> > >> A couple of days ago, bonsaikitten (Patrick), kerframil (Kerin > >> Millar) and myself were talking about other distros moving away > >> from setuid binaries towards caps. Openwall and Fedora are now > >> setuid-less [1]. Some googling showed that Constanze has done > >> quite a bit of work in the area and that there was a consensus to > >> include functions to set caps within portage [2]. I don't know > >> what, if anything has been done since then, but I'd like to lend > >> my support. > >> > > One problem that came up was that a lot of people use tmpfs for > > /var/tmp/portage, and tmpfs doesn't support xattrs which are needed > > for setting caps. > > > > Linux 3.0 has added support for xattrs with tmpfs (the redhat folks > > did the work, afaik), so that problem is partly solved now. > > I know, there are lots of places where xattrs is not supported that > lead to the same problem. I'm tempted to respond with pkg_postinst() > but I see QA problems written all over that. We can either do that or 'Future EAPI' capsetting in PMS. Then, a PM could implement capsetting functions in a such way that they will preserve caps internally to PM and re-set them when merging to livefs. -- Best regards, Michał Górny signature.asc Description: PGP signature
