[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Extra files in build container

From: Ludovic Courtès
Subject: Re: Extra files in build container
Date: Mon, 19 Jun 2017 16:49:43 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)


Gregor Giesen <address@hidden> skribis:

> On Mon, Jun 19, 2017 at 13:26AM +0200 Ludovic Courtès wrote:
>>> On Fri, Jun 16, 2017 at 09:58:55AM +0200, Ludovic Courtès wrote:
>>>> In cases like the one you describe, we usually end up modifying tests to
>>>> use the numerical values for services and protocols rather than their
>>>> names.
>>> Unfortunately, this turns out to be quite cumbersome since in my case
>>> (unittests for unbound) there is a lot of test data to be modified and
>>> in many cases not only plain text but also encrypted records (DNSSEC
>>> tests). On the other hand the values to be looked up are mostly “udp”
>>> and “tcp” in /etc/protocols and “domain” in /etc/services, so I decided
>>> that using a preload library for these few glibc calls just in case of
>>> the unittest should do the trick rather than no checks at all.
>> I think it would be easier to just use ‘substitute*’ to replace all the
>> occurrences of “tcp”, etc., wouldn’t it?
> alas many occurences of "tcp", "udp", etc. are hidden in
> encrypted/hashed records, so simple plain text substitutions would
> break the signatures.

Yes, I can imagine.  But maybe (maybe not!), by selecting the right set
of files to modify, and by adjusting the regexp (let’s say “\<tcp\>” or
“"tcp"”) to match only what matters, it could work.

If that’s really not workable, then the LD_PRELOAD approach is fine.

>>> However, it is an ugly hack and bloats the package definition.
>> I agree, but it’s hard to improve on it without compromising
>> reproducibility.
> It's a good thing that the hack only affects the tests rather than any
> installation files.
> I have submitted the package in a patch yesterday (27419). I wonder
> whether one might want to put the source code of the preload library
> in an extra file rather than the package definition?

Since it’s small I think it’s OK as inline code.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]