From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yann E. MORIN Date: Tue, 26 Mar 2019 23:01:53 +0100 Subject: [Buildroot] [PATCH v2 1/1] package/ecryptfs-utils: Add support without gettext In-Reply-To: <20190326210943.r5vekesv2ipifpwv@vkochan-ThinkPad-T470p> References: <20190315023456.15988-1-vadim4j@gmail.com> <20190326192819.GL2660@scaer> <20190326210943.r5vekesv2ipifpwv@vkochan-ThinkPad-T470p> Message-ID: <20190326220153.GN2660@scaer> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net Vadim, All, On 2019-03-26 23:09 +0200, Vadim Kochan spake thusly: > On Tue, Mar 26, 2019 at 08:28:19PM +0100, Yann E. MORIN wrote: > > On 2019-03-15 04:34 +0200, Vadim Kochan spake thusly: > > > Add custom ecryptfs-common script which provides gettext wrapper as [--SNIP--] > > I know you've pourred quite some effort into this solution, but I am > > still not entirely convinced. > > > > So, my position on how we should handle this in Buildroot is as follows: > > > > 1. When the real 'gettext' utility is not available (for whatever > > reason), then we should install our own, fake gettext, like the one > > I previously suggested. > > > > 2. If you are really interested, push a change upstream that makes > > ecryptfs-utils not require gettext, but with a solution that does > > not use a wrapper. see below for more on that. > > > > 3. If/when upstream supports running without a gettext utility, then > > we can either bump the version in Buildroot, or backport the > > patches. [--SNIP--] > > > ++ src/utils/ecryptfs-migrate-home:src/utils/ecryptfs-migrate-home > > > ++ src/utils/ecryptfs-mount-private:src/utils/ecryptfs-mount-private > > > ++ src/utils/ecryptfs-rewrite-file:src/utils/ecryptfs-rewrite-file > > > ++ src/utils/ecryptfs-setup-private:src/utils/ecryptfs-setup-private > > > ++ src/utils/ecryptfs-setup-swap:src/utils/ecryptfs-setup-swap > > > ++ src/utils/ecryptfs-umount-private:src/utils/ecryptfs-umount-private > > > ++ src/utils/ecryptfs-verify:src/utils/ecryptfs-verify > > > > Since those will now undergo pattern substitution, they should be > > renamed with a .in extension. > > > > Also, it is usualy bad practice to generate such scripts from configure. > > Instead, they should be generated in Makefile.am as new targets. Yes, > > You meant - replace inclusion of this ecryptfs-utils from Makefile.am ? Yes. That would IMHO be the best. But if upstream is willing to take a patch that generates them from configure, I won't be picky! ;-) So, you could keep them generated by configure and send the patch upstream, and see what they say about it. > > this is a bit more involved, but is much cleaner: when you change such a > > script, you just have to run 'make' again, rather than re-run configure. > > > > > ++commonlibdir=$(libdir)/ecryptfs-utils > > > ++commonlib_SCRIPTS=ecryptfs-common > > > > I think 'sh-functions' is more appropriate. > > > > So, in case of (2) then we should wait till ecryptfs's community > apply the solution. Before we can use it in Buildroot? Yes. > In case of gettext-tiny ... as I remember Thomas did > not like the idea with using gettext-tiny for target :), We discussed this live a few days ago, and I think I could somehow mostly convince him. I think. Probably. ;-) He also inquired on IRC a few hours ago about my opinion, and after I exposed it, he asked that I did the reply to you. So again, I think he mostly aligns with the idea now. Hopefully! ;-) > ehhh ... but I > totally AGREE with you because your suggestions are more clear and well > defined, what I tried - is to provide solution which touches not so much > ectyptfs's sources but provides solution w/o gettext to finally close > one gap with gettext-tiny solution :) Yes, this is an "easier" first step, at least. > Back to gettext-tiny, may be it is OK to start with providing > gettext-tiny (as target's gettext provider) just only with this gettext > wrapper (which you suggested previously), and after take gettext-tiny > patches (which I sent and Thomas adapted in his repo) and merge with > solution which provides just gettext util. Sorry, I am not sure I understood the above. When we introduce gettext-tiny, it should also install this fake gettext. I.e. gettext-tiny is as much as possible a drop-in replacement for the real gettext (the package) and thus shall provide gettext (the program). > Thanks Yann with your suggestions. My pleasure. And thank you for staying afloat with the back-and-forth mind-switching there's been on this series. ;-) Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'