[Buildroot] [PATCH v2 1/1] package/ecryptfs-utils: Add support without gettext
Yann E. MORIN
yann.morin.1998 at free.fr
Tue Mar 26 22:01:53 UTC 2019
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. |
'------------------------------^-------^------------------^--------------------'
More information about the buildroot
mailing list