[Buildroot] [PATCH v2 1/1] package/ecryptfs-utils: Add support without gettext

[Yann E. MORIN <yann.morin.1998@free.fr>]

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.  |
'------------------------------^-------^------------------^--------------------'