Re: How to change config script for multiarch?

2016-05-09 Thread Matthias Klose

On 09.05.2016 16:37, Jakub Wilk wrote:

* Helmut Grohne , 2016-05-09, 06:47:

The first misconception I see in this thread is that somehow pkg-config is
good and foo-config is bad. It's not as simple as that. Have a look at
libpython3-dev. It ships e.g. x86_64-linux-gnu-python3-config.


This is an unfortunate example, because Python upstream supports pkg-config,
unlike arch-qualified python*-config. (Why do we need the latter then? Go 
figure.)


because it's still used in upstream m4 macros, which are not yet updated. Go fix 
these upstream at least?



So when converting your foo-config scripts to use pkg-config, you can go ahead
and parse $0. Use that triplet instead of encoding it into your script. Then
each libfoo-dev instance can place the same (shared) foo-config script in a
shared location and place individual symbolic links with the prefix at it.


But then to actually take advantage of the newfangled -foo-config,
you'll have to patch foo-config users. So why not patch them to use
-pkg-config directly?


Here are my foo-config vs Multi-Arch tips:

* Don't read descriptions of old-style-config-script* Lintian tags. They are 
awful.

* It's often possible to make the script architecture-independent with little
work. See #796770 for example.

* If the above doesn't work (or even if it does!), try persuading upstream to
ship pkg-config files. And maybe ask them to deprecate foo-config. This might
let you drop the foo-config in the (very far) future.

If none of this works, it's probably not the end of the world if your -dev
package is not MA:same. Creating -foo-config, especially when it's not
going to be adopted upstream, is most likely counter-productive.


I disagree on this. just split it out into it's own binary package, and fix the 
breakage afterwards. Ship this -bin package for one release, and then drop it if 
you don't have any rdeps.




Re: How to change config script for multiarch?

2016-05-09 Thread Jakub Wilk

* Helmut Grohne , 2016-05-09, 06:47:
The first misconception I see in this thread is that somehow pkg-config 
is good and foo-config is bad. It's not as simple as that. Have a look 
at libpython3-dev. It ships e.g. x86_64-linux-gnu-python3-config.


This is an unfortunate example, because Python upstream supports 
pkg-config, unlike arch-qualified python*-config. (Why do we need the 
latter then? Go figure.)


So when converting your foo-config scripts to use pkg-config, you can 
go ahead and parse $0. Use that triplet instead of encoding it into 
your script. Then each libfoo-dev instance can place the same (shared) 
foo-config script in a shared location and place individual symbolic 
links with the prefix at it.


But then to actually take advantage of the newfangled 
-foo-config, you'll have to patch foo-config users. So why not 
patch them to use -pkg-config directly?



Here are my foo-config vs Multi-Arch tips:

* Don't read descriptions of old-style-config-script* Lintian tags. They 
are awful.


* It's often possible to make the script architecture-independent with 
little work. See #796770 for example.


* If the above doesn't work (or even if it does!), try persuading 
upstream to ship pkg-config files. And maybe ask them to deprecate 
foo-config. This might let you drop the foo-config in the (very far) 
future.


If none of this works, it's probably not the end of the world if your 
-dev package is not MA:same. Creating -foo-config, especially 
when it's not going to be adopted upstream, is most likely 
counter-productive.


And some general tips:

* Do not introduce Debian-specific interfaces.

* Do not remove upstream-supported interfaces, specially when no 
upstream-supported alternatives exist.


--
Jakub Wilk



Re: How to change config script for multiarch?

2016-05-09 Thread Simon McVittie
On Mon, 09 May 2016 at 06:47:38 +0200, Helmut Grohne wrote:
> In order for pkg-config to be "better" than your foo-config script, you
> need to tell it about the current host architecture by prefixing it with
> the triplet. Instead of calling pkg-config, you should be calling
> $DEB_HOST_GNU_TYPE-pkg-config. The tricky question is: Where to obtain
> that value. The answer is: By parsing $0.

The reason this works is that third-party configure scripts (for users of
foo) normally call the PKG_PROG_PKG_CONFIG Autoconf macro, either directly
or via PKG_CHECK_MODULES or PKG_CHECK_EXISTS, and PKG_PROG_PKG_CONFIG
correctly uses AC_PATH_TOOL to look for the tuple-prefixed version before
the unprefixed version.

If users of foo normally call foo-config directly, no amount of adding
prefixes is going to make them cross-build without modification.

S



Re: How to change config script for multiarch?

2016-05-08 Thread Helmut Grohne
On Wed, Feb 10, 2016 at 11:03:04AM +0100, Bastien ROUCARIES wrote:
> On Wed, Feb 10, 2016 at 10:59 AM, Alastair McKinstry
> > In particular, for any non-standard variables, you can read them, by eg:
> >
> > f90_compiler=$(pkg-config mypkg --variable=f90_compiler)
> >
> > Its probably a good idea to document the config script as deprecated
> > in output, the man page, etc.
> 
> (2) wrapper are not cross build safe...

This seems less than constructive, so let me briefly follow up on how to
make it work properly.

The first misconception I see in this thread is that somehow pkg-config
is good and foo-config is bad. It's not as simple as that. Have a look
at libpython3-dev. It ships e.g. x86_64-linux-gnu-python3-config. By
prefixing the script with the triplet, we can treat it very much like
libraries that are being placed in multiarch locations.

In order for pkg-config to be "better" than your foo-config script, you
need to tell it about the current host architecture by prefixing it with
the triplet. Instead of calling pkg-config, you should be calling
$DEB_HOST_GNU_TYPE-pkg-config. The tricky question is: Where to obtain
that value. The answer is: By parsing $0.

So when converting your foo-config scripts to use pkg-config, you can go
ahead and parse $0. Use that triplet instead of encoding it into your
script. Then each libfoo-dev instance can place the same (shared)
foo-config script in a shared location and place individual symbolic
links with the prefix at it. Alternatively, you can do like python and
ship plain files in triplet-prefixed locations. No pkg-config. Still
M-A:same safe.

It is worth noting that pkg-config has a head-start here. It implements
the parsing of $0 for you. It also improves the client side.  For this
change to work properly, consumers must call your foo-config with the
triplet prefix. When you use autotools, it'll automatically prefer the
prefixed pkg-config over the plain one (unless your pkg-config code is
home-grown).

It's not like pkg-config is the silver bullet here. It just helps you
solve some of the integration problems.

Finally, turning Multi-Arch off for libfoo-dev packages may sound bad,
but in many cases it is actually harmless to practical cross building.
libgpg-error-dev has it turned off and still works well in practise.

There is a trade-off between backwards compatibility, multiarch support
and time investment to be made in these cases. I do not believe that
pkg-config is the one-size-fits-all answer.

Helmut



Re: How to change config script for multiarch?

2016-02-13 Thread Paul Wise
On Fri, Feb 12, 2016 at 8:10 PM, Bastien Roucaries wrote:

> i will open a wiki page including this thread comments

No need to duplicate the official documentation:

https://sources.debian.net/doc/url/

Also no need to CC me.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: How to change config script for multiarch?

2016-02-12 Thread Bastien Roucaries


Le 12 février 2016 02:02:53 GMT+01:00, Paul Wise  a écrit :
>On Wed, Feb 10, 2016 at 9:09 PM, Johannes Schauer wrote:
>
>> A bit OT: the old-style-config-script lintian description links to a
>404 page
>> on sources.debian.net. Maybe this link should be updated? Is there a
>way to
>> create a link to a file on sources.debian.net where, if the version
>doesn't
>> exist anymore, it will automatically fall-back to the next highest
>version?
>
>You can use 'latest' or any suite (unstable/testing/etc) or codename
>(sid/jessie/etc) in the version part of the URL to avoid broken links.
>Of course if the layout of a source package changes then the link
>could break, that shouldn't be an issue here though.

i will open a wiki page including this thread comments

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.



Re: How to change config script for multiarch?

2016-02-12 Thread Johannes Schauer
Hi,

Quoting Bastien Roucaries (2016-02-12 10:10:10)
> Le 12 février 2016 02:02:53 GMT+01:00, Paul Wise  a écrit :
> >On Wed, Feb 10, 2016 at 9:09 PM, Johannes Schauer wrote:
> >
> >> A bit OT: the old-style-config-script lintian description links to a
> >404 page
> >> on sources.debian.net. Maybe this link should be updated? Is there a
> >way to
> >> create a link to a file on sources.debian.net where, if the version
> >doesn't
> >> exist anymore, it will automatically fall-back to the next highest
> >version?
> >
> >You can use 'latest' or any suite (unstable/testing/etc) or codename
> >(sid/jessie/etc) in the version part of the URL to avoid broken links.
> >Of course if the layout of a source package changes then the link
> >could break, that shouldn't be an issue here though.
> 
> i will open a wiki page including this thread comments

indeed it would've helped if I would've read the sources.d.n docs before asking
my original question. It is documented here:

http://sources.debian.net/doc/url/

under "Navigation within a package"

Thanks!

cheers, josch


signature.asc
Description: signature


Re: upstream_version not starting with a digit (was: Re: How to change config script for multiarch?)

2016-02-12 Thread Jakub Wilk

* Johannes Schauer , 2016-02-12, 13:41:

dpkg-buildpackage: warning: debian/changelog(l1): version '0:jessie' is 
invalid: version number does not start with digit
LINE: name (0:jessie) unstable; urgency=medium

According to the following regex over my Sources there seems to be no 
source package with an upstream_version part that does not start with a 
digit:


sed -ne 's/^Version: \([0-9]\+:\)\?[^0-9]//p'

So maybe policy should be adjusted to reflect reality?


Yes. #620566 used to be a policy bug about it, but then someone 
unhelpfully reassigned it to dpkg...


--
Jakub Wilk



upstream_version not starting with a digit (was: Re: How to change config script for multiarch?)

2016-02-12 Thread Johannes Schauer
Hi,

Quoting Paul Wise (2016-02-12 02:02:53)
> On Wed, Feb 10, 2016 at 9:09 PM, Johannes Schauer wrote:
> > A bit OT: the old-style-config-script lintian description links to a 404 
> > page
> > on sources.debian.net. Maybe this link should be updated? Is there a way to
> > create a link to a file on sources.debian.net where, if the version doesn't
> > exist anymore, it will automatically fall-back to the next highest version?
> 
> You can use 'latest' or any suite (unstable/testing/etc) or codename
> (sid/jessie/etc) in the version part of the URL to avoid broken links.

I was about to ask what would happen if somebody would introduce a native
Debian package with upstream_version "jessie". As far as I see, this would be
legal according to policy because §5.6.12 only says that the upstream_version
part "should" start with a digit.

Though when I then tried to create such a package, dpkg refused to cooperate:

dpkg-buildpackage: warning: debian/changelog(l1): version '0:jessie' is 
invalid: version number does not start with digit
LINE: name (0:jessie) unstable; urgency=medium

According to the following regex over my Sources there seems to be no source
package with an upstream_version part that does not start with a digit:

sed -ne 's/^Version: \([0-9]\+:\)\?[^0-9]//p'

So maybe policy should be adjusted to reflect reality?

cheers, josch


signature.asc
Description: signature


Re: How to change config script for multiarch?

2016-02-11 Thread NOKUBI Takatsugu
At Fri, 12 Feb 2016 01:12:43 +0100,
Jakub Wilk wrote:
> I don't know much about this package, but codesearch.d.n tells me that
> all users of chasen-config call it with the --mkchadic option, which
> causes the script to print /usr/lib//chasen/, which is a
> directory shipped by chasen-config. So it's not completely
> unrelated...

Oh, you are right. And it was already used and dependend in naist-jdic
package. I'll fix it.

> And, as it turns out, the implementation of --mkchadic is the only
> part of the config script that uses the multi-arch triplet in a way
> that can't be trivially patched-out. (The only other place where the
> triplet is used is --libs, where the script prints
> "-L${prefix}/lib/"; but this -L is a no-op that can be
> removed.)

Indeed. I'll remove it.



Re: How to change config script for multiarch?

2016-02-11 Thread Jakub Wilk

* Johannes Schauer , 2016-02-10, 11:09:
I am a maintainer of chasen package. It contains chasen-config, it 
work as pkg-config like but it's a single script.


Latest lintain reports:
E: libchasen-dev: old-style-config-script-multiarch-path usr/bin/chasen-config 
full text contains architecture specific dir x86_64-linux-gnu

But I want to keep libchasen-dev as Multi-Arch: same. Would you tell 
me finding the correct way to change the script?

[...]
The old-style-config-script tag which src:chasen suffers from as well 
and which was also linked to by Bastien contains more valuable 
information. The important message is: please use pkg-config and not 
some package-specific configuration mechanism (as also already pointed 
out by Vincent). Otherwise, you (and/or upstream) will suffer from an 
unnecessary maintenance burden in case you ever want to (or in case we 
need to) cross-build that source package. For now though it should be 
sufficient to move the file into an architecture specific path.


Um, no. Replacing an upstream-supported API, which has existing users 
even in the Debian archive, with a Debian-specific non-upstreamable one 
sounds like a very bad plan to me.


--
Jakub Wilk



Re: How to change config script for multiarch?

2016-02-11 Thread Johannes Schauer
Hi,

Quoting Jakub Wilk (2016-02-11 12:44:34)
> * Johannes Schauer , 2016-02-10, 11:09:
> >The old-style-config-script tag which src:chasen suffers from as well and
> >which was also linked to by Bastien contains more valuable information. The
> >important message is: please use pkg-config and not some package-specific
> >configuration mechanism (as also already pointed out by Vincent). Otherwise,
> >you (and/or upstream) will suffer from an unnecessary maintenance burden in
> >case you ever want to (or in case we need to) cross-build that source
> >package. For now though it should be sufficient to move the file into an
> >architecture specific path.
> 
> Um, no. Replacing an upstream-supported API, which has existing users 
> even in the Debian archive, with a Debian-specific non-upstreamable one
> sounds like a very bad plan to me.

please excuse my bad phrasing of my last message. When I said "please use
pkg-config" then I didn't mean "please do X without consulting and
collaborating with upstream". Indeed it would be best if you could convince
upstream to switch to pkg-config and not make the change Debian specific unless
there is more pressing need for doing so.

Thanks!

cheers, josch


signature.asc
Description: signature


Re: How to change config script for multiarch?

2016-02-11 Thread Jakub Wilk

* NOKUBI Takatsugu , 2016-02-12, 08:27:

Jakub Wilk wrote:
Are you trying to move the script to libchasen-dev? Why? There are 
Debian maintainer scripts that use chasen-config. Are they going to 
depend on the -dev package?


Yes, now I will move the script into libchasen-dev because it seems 
make sense, chasen-config is not related with chasen dictionaries.


I don't know much about this package, but codesearch.d.n tells me that 
all users of chasen-config call it with the --mkchadic option, which 
causes the script to print /usr/lib//chasen/, which is a 
directory shipped by chasen-config. So it's not completely unrelated...


And, as it turns out, the implementation of --mkchadic is the only part 
of the config script that uses the multi-arch triplet in a way that 
can't be trivially patched-out. (The only other place where the triplet 
is used is --libs, where the script prints "-L${prefix}/lib/"; 
but this -L is a no-op that can be removed.)


--
Jakub Wilk



Re: How to change config script for multiarch?

2016-02-11 Thread Paul Wise
On Wed, Feb 10, 2016 at 9:09 PM, Johannes Schauer wrote:

> A bit OT: the old-style-config-script lintian description links to a 404 page
> on sources.debian.net. Maybe this link should be updated? Is there a way to
> create a link to a file on sources.debian.net where, if the version doesn't
> exist anymore, it will automatically fall-back to the next highest version?

You can use 'latest' or any suite (unstable/testing/etc) or codename
(sid/jessie/etc) in the version part of the URL to avoid broken links.
Of course if the layout of a source package changes then the link
could break, that shouldn't be an issue here though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: How to change config script for multiarch?

2016-02-11 Thread Paul Wise
On Fri, Feb 12, 2016 at 10:20 AM, NOKUBI Takatsugu wrote:

> I am also a member of the upstream, but the software is now under
> maintainance phase, so it is hard to accept using pkg-config insead of
> the current script.
> I consider to use pkg-config on debian specific patch in the future.

There are non-Debian distributions that are focused on cross-building,
I think it would be better if you did the change upstream so that they
can cross-build chasen too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: How to change config script for multiarch?

2016-02-11 Thread NOKUBI Takatsugu
At Wed, 10 Feb 2016 13:17:50 +0100,
Jakub Wilk wrote:
> Are you trying to move the script to libchasen-dev? Why? There are
> Debian maintainer scripts that use chasen-config. Are they going to
> depend on the -dev package?

Yes, now I will move the script into libchasen-dev because it seems
make sense, chasen-config is not related with chasen dictionaries.



Re: How to change config script for multiarch?

2016-02-11 Thread NOKUBI Takatsugu
Thank you your good answer.

At Wed, 10 Feb 2016 08:34:10 +0100,
Vincent Danjean wrote:
>   I do not think there is a generic answer. But, if your script is
> simple, perhaps just replacing hardcoded directory names by the output
> of "dpkg -qDEB_HOST_MULTIARCH" will be enough.

I think "dpkg-architecture -qDEB_HOST_MULTIARCH)" is the right
command, not dpkg right?

>   Note that this won't solve cross-compilation issues. For this, unless
> specific needs, a convertion to pkg-config style is probably the
> easiest/rightest (but it is better to do it with upstream). In this
> case, the chasen-config might be rewritten with internal calls to
> pkg-config to avoid to duplicate the information and still keeping
> the old interface.

I am also a member of the upstream, but the software is now under
maintainance phase, so it is hard to accept using pkg-config insead of
the current script.
I consider to use pkg-config on debian specific patch in the future.

Thank you again.



Re: How to change config script for multiarch?

2016-02-10 Thread Bastien ROUCARIES
On Wed, Feb 10, 2016 at 8:12 AM, NOKUBI Takatsugu  wrote:
> I am a maintainer of chasen package. It contains chasen-config, it
> work as pkg-config like but it's a single script.
>
> Latest lintain reports:
> E: libchasen-dev: old-style-config-script-multiarch-path 
> usr/bin/chasen-config full text contains architecture specific dir 
> x86_64-linux-gnu
>
> But I want to keep libchasen-dev as Multi-Arch: same. Would you tell
> me finding the correct way to change the script?
>
See https://lintian.debian.org/tags/old-style-config-script.html



Re: How to change config script for multiarch?

2016-02-10 Thread Alastair McKinstry

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi ,

I've solved this problem by:
(1) creating a pkg-config script, adding it as multiarch.
(2) editing the config script to use the pkg-config script.

In particular, for any non-standard variables, you can read them, by eg:

f90_compiler=$(pkg-config mypkg --variable=f90_compiler)

Its probably a good idea to document the config script as deprecated
in output, the man page, etc.

regards
Alastair


On 10/02/2016 07:12, NOKUBI Takatsugu wrote:
> I am a maintainer of chasen package. It contains chasen-config, it
> work as pkg-config like but it's a single script.
>
> Latest lintain reports:
> E: libchasen-dev: old-style-config-script-multiarch-path
usr/bin/chasen-config full text contains architecture specific dir
x86_64-linux-gnu
>
> But I want to keep libchasen-dev as Multi-Arch: same. Would you tell
> me finding the correct way to change the script?
>
>
> --
> Alastair McKinstry, , ,
https://diaspora.sceal.ie/u/amckinstry
> Misentropy: doubting that the Universe is becoming more disordered.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWuwoCAAoJEMvmu05dmtOlhiUP/AuG7t8pMlzb4sgzvO//xAGK
O8aNRi789Yun4svsClBFrO/lv2GcynH5h6fqLL1oAndmBCX5cuMqjCwzUEEngCcK
Z5JiQ4MoQvFTqAneN0WGsvDPbq0Ofg6Lfti/FO3OsD6emvSn/f5f1RaF5mrd8vRd
SolUJDjtABV6DVqX8tY8rbf7u/ecdeYq0zMnEPsKEnUgrNSJQLGm0XC5YyANeDcG
2kpxPtPhHF9yz0yqV/hqiYTjDFR53vY29q/9QjjI9amdEV2btdeVf5cvtGFwXNQm
qL3VpeD0jbzMFYyIfcQy4IjhENkijyWl4BP9MD3sJ3vSpEjmLIfw5PGHVn2PgoEz
8zuAT4ub0D0ANRkA2JRLk9fVHtmGtEa4l2lpEztv4HeBeitEbKllOGQ1pU/GROax
2CmiGnxhG74T2qFC0bPDqHMKsc8W3SdXs6uYkuv+4WXiPuul14oD/7nOltGUc1p4
WHS5qSAZ/CV/madVZw1oeYDctehLYMk5RjYM32VO26lAoz0RkhAopdfmk+8QFUV8
nOJG2PKj1s4E3kJPZk2uLiFRSdhZe9PZXPnGcbJBpiEEw/Yo/6uhLOrm+n43gi/N
ZAPWnWuEMY/22r7XJg0NQwmNCCPSqGeUVG2k18A7nYlf/eIY+lhnauJUwpKEFass
JaVBSA7Fop2V1sPkOVzS
=84mc
-END PGP SIGNATURE-



Re: How to change config script for multiarch?

2016-02-10 Thread Johannes Schauer
Hi Nokubi,

Quoting Bastien ROUCARIES (2016-02-10 10:29:46)
> On Wed, Feb 10, 2016 at 8:12 AM, NOKUBI Takatsugu  wrote:
> > I am a maintainer of chasen package. It contains chasen-config, it
> > work as pkg-config like but it's a single script.
> >
> > Latest lintain reports:
> > E: libchasen-dev: old-style-config-script-multiarch-path 
> > usr/bin/chasen-config full text contains architecture specific dir 
> > x86_64-linux-gnu
> >
> > But I want to keep libchasen-dev as Multi-Arch: same. Would you tell
> > me finding the correct way to change the script?
> >
> See https://lintian.debian.org/tags/old-style-config-script.html

your message would've been a better fit for debian-ment...@lists.debian.org

You can see an explanation of lintian tags by doing:

$ lintian-info --tags old-style-config-script-multiarch-path

The old-style-config-script tag which src:chasen suffers from as well and which
was also linked to by Bastien contains more valuable information. The important
message is: please use pkg-config and not some package-specific configuration
mechanism (as also already pointed out by Vincent). Otherwise, you (and/or
upstream) will suffer from an unnecessary maintenance burden in case you ever
want to (or in case we need to) cross-build that source package. For now though
it should be sufficient to move the file into an architecture specific path.

A bit OT: the old-style-config-script lintian description links to a 404 page
on sources.debian.net. Maybe this link should be updated? Is there a way to
create a link to a file on sources.debian.net where, if the version doesn't
exist anymore, it will automatically fall-back to the next highest version?

Thanks!

cheers, josch


signature.asc
Description: signature


Re: How to change config script for multiarch?

2016-02-10 Thread Bastien ROUCARIES
On Wed, Feb 10, 2016 at 10:59 AM, Alastair McKinstry
 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi ,
>
> I've solved this problem by:
> (1) creating a pkg-config script, adding it as multiarch.
> (2) editing the config script to use the pkg-config script.
>
> In particular, for any non-standard variables, you can read them, by eg:
>
> f90_compiler=$(pkg-config mypkg --variable=f90_compiler)
>
> Its probably a good idea to document the config script as deprecated
> in output, the man page, etc.

(2) wrapper are not cross build safe...

> regards
> Alastair

>
> On 10/02/2016 07:12, NOKUBI Takatsugu wrote:
>> I am a maintainer of chasen package. It contains chasen-config, it
>> work as pkg-config like but it's a single script.
>>
>> Latest lintain reports:
>> E: libchasen-dev: old-style-config-script-multiarch-path
> usr/bin/chasen-config full text contains architecture specific dir
> x86_64-linux-gnu
>>
>> But I want to keep libchasen-dev as Multi-Arch: same. Would you tell
>> me finding the correct way to change the script?
>>
>>
>> --
>> Alastair McKinstry, , ,
> https://diaspora.sceal.ie/u/amckinstry
>> Misentropy: doubting that the Universe is becoming more disordered.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJWuwoCAAoJEMvmu05dmtOlhiUP/AuG7t8pMlzb4sgzvO//xAGK
> O8aNRi789Yun4svsClBFrO/lv2GcynH5h6fqLL1oAndmBCX5cuMqjCwzUEEngCcK
> Z5JiQ4MoQvFTqAneN0WGsvDPbq0Ofg6Lfti/FO3OsD6emvSn/f5f1RaF5mrd8vRd
> SolUJDjtABV6DVqX8tY8rbf7u/ecdeYq0zMnEPsKEnUgrNSJQLGm0XC5YyANeDcG
> 2kpxPtPhHF9yz0yqV/hqiYTjDFR53vY29q/9QjjI9amdEV2btdeVf5cvtGFwXNQm
> qL3VpeD0jbzMFYyIfcQy4IjhENkijyWl4BP9MD3sJ3vSpEjmLIfw5PGHVn2PgoEz
> 8zuAT4ub0D0ANRkA2JRLk9fVHtmGtEa4l2lpEztv4HeBeitEbKllOGQ1pU/GROax
> 2CmiGnxhG74T2qFC0bPDqHMKsc8W3SdXs6uYkuv+4WXiPuul14oD/7nOltGUc1p4
> WHS5qSAZ/CV/madVZw1oeYDctehLYMk5RjYM32VO26lAoz0RkhAopdfmk+8QFUV8
> nOJG2PKj1s4E3kJPZk2uLiFRSdhZe9PZXPnGcbJBpiEEw/Yo/6uhLOrm+n43gi/N
> ZAPWnWuEMY/22r7XJg0NQwmNCCPSqGeUVG2k18A7nYlf/eIY+lhnauJUwpKEFass
> JaVBSA7Fop2V1sPkOVzS
> =84mc
> -END PGP SIGNATURE-
>



Re: How to change config script for multiarch?

2016-02-10 Thread Simon McVittie
On Wed, 10 Feb 2016 at 11:03:04 +0100, Bastien ROUCARIES wrote:
> On Wed, Feb 10, 2016 at 10:59 AM, Alastair McKinstry
>  wrote:
> > I've solved this problem by:
> > (1) creating a pkg-config script, adding it as multiarch.
> > (2) editing the config script to use the pkg-config script.
> 
> (2) wrapper are not cross build safe...

Correct, but the existence of a foo-config script is not something
that Debian should unilaterally change. Upstream software that depends
on foo is still going to try to run foo-config, until/unless there is
a release of foo that deprecates foo-config and provides equivalent
pkg-config files.

In other words, please talk to the upstream maintainers
about adding pkg-config metadata and specifically deprecating
foo-config. Debian-specific patches can only benefit Debian and its
derivatives, upstream fixes benefit everyone.

S



Re: How to change config script for multiarch?

2016-02-10 Thread Jakub Wilk

* NOKUBI Takatsugu , 2016-02-10, 16:12:
I am a maintainer of chasen package. It contains chasen-config, it work 
as pkg-config like but it's a single script.


Latest lintain reports:
E: libchasen-dev: old-style-config-script-multiarch-path usr/bin/chasen-config 
full text contains architecture specific dir x86_64-linux-gnu


There is no chasen-config in the latest version of libchasen-dev 
(2.4.5-21).


chasen-config is currently shipped in chasen-dictutils, for which 
Lintian incorrectly emits this tag. This will be fixed in the next 
Lintian release.


Are you trying to move the script to libchasen-dev? Why? There are 
Debian maintainer scripts that use chasen-config. Are they going to 
depend on the -dev package?


But I want to keep libchasen-dev as Multi-Arch: same. Would you tell me 
finding the correct way to change the script?


It's hard to give a concrete answer without seeing the package you're 
working with; or at least without explanation how exactly it differs 
from the package in the archive.


--
Jakub Wilk



Re: How to change config script for multiarch?

2016-02-09 Thread Vincent Danjean
Le 10/02/2016 08:12, NOKUBI Takatsugu a écrit :
> I am a maintainer of chasen package. It contains chasen-config, it
> work as pkg-config like but it's a single script.
> 
> Latest lintain reports:
> E: libchasen-dev: old-style-config-script-multiarch-path 
> usr/bin/chasen-config full text contains architecture specific dir 
> x86_64-linux-gnu
> 
> But I want to keep libchasen-dev as Multi-Arch: same. Would you tell
> me finding the correct way to change the script?

  I do not think there is a generic answer. But, if your script is
simple, perhaps just replacing hardcoded directory names by the output
of "dpkg -qDEB_HOST_MULTIARCH" will be enough.
  This would probably be an debian-specific arch because the script
will then do some assumption about the layout of the software (instead
of relying on the $libdir, ... autoconf variables/substitutions) and
it will use the Debian specific dpkg-architecture tool (your package
will need to depends on dpkg-dev)
  To be Multi-Arch: same, the package must have the same contents in
all architectures.

  Note that this won't solve cross-compilation issues. For this, unless
specific needs, a convertion to pkg-config style is probably the
easiest/rightest (but it is better to do it with upstream). In this
case, the chasen-config might be rewritten with internal calls to
pkg-config to avoid to duplicate the information and still keeping
the old interface.

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main