Re: New conflict on if_wg.h in runtime package

On Wed, 2 Nov 2022 at 16:48, Kyle Evans <kevans@freebsd.org> wrote:

> 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.
>

Is that something you have time to work on? I am very far from
understanding how this stuff works :(