Re: New conflict on if_wg.h in runtime package

On Wed, Nov 2, 2022 at 11:35 AM Doug Rabson <dfr@rabson.org> wrote:
>
>
>
> On Wed, 2 Nov 2022 at 16:30, Kyle Evans <kevans@freebsd.org> wrote:
>>
>> On Wed, Nov 2, 2022 at 11:21 AM Doug Rabson <dfr@rabson.org> wrote:
>> >
>> >
>> >
>> > On Wed, 2 Nov 2022 at 16:07, Guido Falsi <mad@madpilot.net> wrote:
>> >>
>> >> On 02/11/22 16:32, Doug Rabson wrote:
>> >> >
>> >> >
>> >> > On Wed, 2 Nov 2022 at 13:54, Guido Falsi <mad@madpilot.net
>> >> > <mailto:mad@madpilot.net>> wrote:
>> >> >
>> >> >     Hi!
>> >> >
>> >> >     I am trying to upgrade head using packaged base and I'm getting this
>> >> >     error now:
>> >> >
>> >> >     pkg: FreeBSD-runtime-dev-14.snap20221102095743 conflicts with
>> >> >     FreeBSD-runtime-14.snap20221102095743 (installs files into the same
>> >> >     place).  Problematic file: /usr/include/dev/wg/if_wg.h
>> >> >
>> >> >     Looks like for some reason if_wg.h ended up in both packages.
>> >> >
>> >> >     Am I doing something wrong and can I work around this or should this be
>> >> >     fixed in the sources?
>> >> >
>> >> >
>> >> > This seems to be a problem in pkgbase. Packages are built using the
>> >> > metalog generated from the various install commands during the build -
>> >> > if_wg.h has two entries in the metalog, one with
>> >> > tags=package=runtime,dev and one with tags=package=runtime. Can you open
>> >> > a bug on bugs.freebsd.org <http://bugs.freebsd.org>?
>> >> >
>> >> >
>> >>
>> >>
>> >> sure!
>> >
>> >
>> > I think the problem is caused by the 'copies' target in src/include which is where the second metalog entry happens. From my limited understanding, this target shouldn't create metalog entries but I'm not sure how to stop it.
>> >>
>>
>> It's via ${INSTALL}, which uses ${INSTALLFLAGS} that includes metalog
>> bits. The problem is we're using the global ${TAG_ARGS} for those, but
>> that's wrong on a number of levels. All of the headers need, at a
>> minimum, a version of ${TAG_ARGS} that has ,dev, but also a lot of
>> these have their own *PACKAGE that they should go to instead.
>
> That makes sense - for if_wg.h, there is an explicit entry in the WG group which does get installed with ,dev.
>

I think the end-result is that we actually *only* want the entries
from the copies (or symlinks) targets so that we preserve the final
state, even though it's pretty much just going to be copies for most
people. We just need to restructure those to more surgically operate
on INCS/INCSGROUPS.