[wpkg-users] Host match disruptive changes in 1.2?

Rainer Meier r.meier at wpkg.org
Tue Jul 19 15:39:51 CEST 2011


Hi Heiko,

On 19.07.2011 13:51, heiko.helmle at horiba.com wrote:
>  > information you provide it seems to be logical and intentional for
>  > me that the
>  > "default" profile is applied to the host since your name="." would
>  > match all the
>  > hosts. If you don't intend to match them all then make sure
>  > hosts.xml does not
>  > contain such a "catch all" host entry which will match any host name. Either
>  > sort the host entries in your hosts.xml or make sure you literally sort your
>  > hosts/*.xml files and only the last one contains such a "catch all" entry.
>  >
>
> Darn I forgot about this.
>
> There was indeed a change I noticed but forgot to open a discussion about it. It
> looks like the order of the xml-files changed during some RC. I remember having
> the catchall in hosts.xml and several normal definitions in the hosts/
> subdirectory. In one RC, WPKG started to load hosts.xml first and the
> definitions in the hosts/ subdirectory after that.

Do you remember which RC this was? It must have been changed unintentionally or 
due to some technical constraints. However I would like to investigate if I have 
a quiet minute.

In fact this might be exactly the problem Marco run into. Earlier versions of 
WPKG might have evaluated hosts/*.xml first and then hosts.xml so his hosts 
would match to any definition hosts/*.xml first.

I think in general the "old" approach was more generic. WPKG should first 
evaluate specific hosts/*.xml definitions before proceeding with hosts.xml.

Honestly I did even not think about this too much before since in my mind people 
were using one or the other, but not both. But as it's technically possible to 
use hosts.xml and hosts/*.xml at the same time I think the old approach was more 
logical.

I will try to find the reason for this. In any case it might break some 
installations because matches might be applied in different order. Of course it 
is supposed to be a very rare problem but nevertheless it breaks seems to have 
an impact on the advertised 100% backwards compatibility. So I think it shall be 
fixed if technically possible.

br,
Rainer



More information about the wpkg-users mailing list