All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 5/6] intltool: refactor with host-perl
Date: Mon, 6 Oct 2014 17:37:46 +0200	[thread overview]
Message-ID: <20141006173746.19e1109d@free-electrons.com> (raw)
In-Reply-To: <CAB0FRsskEMr08iL9=Fcmmi=StVdCPk84jQcJC1V044tUi7hY2Q@mail.gmail.com>

Dear Fran?ois Perrad,

On Wed, 20 Aug 2014 18:45:07 +0200, Fran?ois Perrad wrote:

> host-intltool depends on host-perl-xml-parser,
> and now, host-perl-xml-parser depends on host-perl.
> 
> A host-perl-foo-module cannot depend on host-perl OR system-perl.
> All host-perl-foo-module must depend on host-perl.

Sorry, but it's not acceptable to have host-intltool depend on
host-perl. It's bringing a huge dependency (host-perl) in a large
number of configurations, since host-intltool is used by so many
packages.

I had a discussion with Gustavo about this not long ago, and here is
our proposal: change host-perl-xml-parser to *not* use the perl package
infrastructure, as an exception. This way, it will not depend on
host-perl, and we'll be happy. Of course, it's a bit ugly because we
have a Perl package not handled by the package infrastructure, but
that's a reasonable solution for this problem.

Another approach would be to make host-intltool not depend on
XML::Parser. It seems like it's possible to get rid of the XML::Parser
dependency by passing no-xml as the second argument of the
IT_PROG_INTLTOOL macro. But this needs to be done in each and every
package using intltool. All of the packages that are not using XML
based translation files could pass no-xml, and we would get rid of the
dependency on host-perl-xml-parser for those packages. That could be
one option.

Since the vast majority of projects seem to be using "ini style"
translation files, we could probably use no-xml on many of them and get
rid of the problem.

Thoughts?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

  reply	other threads:[~2014-10-06 15:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-19 18:07 [Buildroot] [PATCH 1/6] perl: add host variant Francois Perrad
2014-08-19 18:07 ` [Buildroot] [PATCH 2/6] perl: remove useless hacks Francois Perrad
2014-08-19 18:07 ` [Buildroot] [PATCH 3/6] pkg-perl: refactor with host-perl Francois Perrad
2014-08-19 18:07 ` [Buildroot] [PATCH 4/6] pkg-perl: add host-perl dependency Francois Perrad
2014-08-19 18:07 ` [Buildroot] [PATCH 5/6] intltool: refactor with host-perl Francois Perrad
2014-08-20 12:21   ` Thomas Petazzoni
2014-08-20 16:45     ` François Perrad
2014-10-06 15:37       ` Thomas Petazzoni [this message]
2014-10-06 17:37         ` [Buildroot] [UNSURE]Re: " François Perrad
2014-08-19 18:07 ` [Buildroot] [PATCH 6/6] metacity: " Francois Perrad

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141006173746.19e1109d@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.