Re: New conflict on if_wg.h in runtime package
- Reply: Kyle Evans : "Re: New conflict on if_wg.h in runtime package"
- In reply to: Kyle Evans : "Re: New conflict on if_wg.h in runtime package"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 02 Nov 2022 16:35:28 UTC
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.