From nobody Wed Nov 02 16:59:32 2022 X-Original-To: freebsd-pkgbase@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N2Y5r5Qj7z4gNdR for ; Wed, 2 Nov 2022 16:59:44 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N2Y5r25LRz3p31 for ; Wed, 2 Nov 2022 16:59:44 +0000 (UTC) (envelope-from dfr@rabson.org) Received: by mail-vs1-xe2b.google.com with SMTP id p4so17850771vsa.11 for ; Wed, 02 Nov 2022 09:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=TNQ2wv9v6JRvQehjvuX6+tb0/9PolI5+hVne/hUDVMo=; b=j5bvhEdoPs6VTWblmh2I9+yXFTkojJ0wbXfmYJxS09188Reoi2ZebbcWDbC3R/ACZJ oaFy/6+x27JpPLQlaqod/KRsutmlfw8XV2TD34I5Yd1ox5G9V2DZpdDwLSQUklViaGpr J5v8VJqkhXLtUpa+HQRi7836TMCB6PPEwFNkkFfbkWRpz4Zf5i8oFWtqrziwxlRVkjlP Gad3YOWba13dE4ETZt3RTiV8UYSNtGK4s3JCOiD/jZMZnfvjeWAL6poJm/HqmBYFpcmR Wv/q9D6YR+pPRSAftV30iWMxfQMdBzwk5+dKeUErA+vux9fgoWY24eGU5MaA+tAsspKX KUFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TNQ2wv9v6JRvQehjvuX6+tb0/9PolI5+hVne/hUDVMo=; b=23zFYkeew0kp7+8R4Hscxg1i3YsxSeGtIiYt6aTFEtOdHGuQisaGoEV1C2LvQN2O1t vU1BcLjB8FbtalhsEkbOr4UMbCWZjPls3WJJFZysBhzRG1mSARz2bIUv+rWFKURU2kds 27c74yRWeAHXxJEQbsfBA5G0RY8YTV9YCEi2/5AeZWMGDSnyGmKZBON4qHQT0Bgy+PtI i19a4jmYSXQQcu6YdVE3mBgpVnU5qYT8/VU44RZJgE8CMzifki0p3Pdq8Pgr6RNJABfB vit+BKsurP8bsqprAEewpSKxNkTtrngwQXWk2te2bZqzS7W6rKjqK4mid9oPV4i5A1Qi Iolw== X-Gm-Message-State: ACrzQf0P4Atrxe3lMy32bvWzh77wPXGVFCngCkGp+tQhjceNmyzxhhf6 4LA+Zxb8+6D/bvkSgeO+WjS/qIM+I6xXAM0KU6n8aVetZVM= X-Google-Smtp-Source: AMsMyM6WrJT2WcqIkliexF0Z2iv2AtY7y8tlsUg4t0tGlHFgDu0/mnSkJ0B/1fIU58AdE6X9GESeoBL5TgojtjfjK7o= X-Received: by 2002:a67:1902:0:b0:3aa:3c4c:72c4 with SMTP id 2-20020a671902000000b003aa3c4c72c4mr12256109vsz.67.1667408383538; Wed, 02 Nov 2022 09:59:43 -0700 (PDT) List-Id: Packaging the FreeBSD base system List-Archive: https://lists.freebsd.org/archives/freebsd-pkgbase List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pkgbase@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Doug Rabson Date: Wed, 2 Nov 2022 16:59:32 +0000 Message-ID: Subject: Re: New conflict on if_wg.h in runtime package To: Kyle Evans Cc: Guido Falsi , freebsd-pkgbase@freebsd.org Content-Type: multipart/alternative; boundary="0000000000006594f805ec7fc45a" X-Rspamd-Queue-Id: 4N2Y5r25LRz3p31 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rabson-org.20210112.gappssmtp.com header.s=20210112 header.b=j5bvhEdo; dmarc=none; spf=pass (mx1.freebsd.org: domain of dfr@rabson.org designates 2607:f8b0:4864:20::e2b as permitted sender) smtp.mailfrom=dfr@rabson.org X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[rabson-org.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2b:from]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-pkgbase@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[rabson-org.20210112.gappssmtp.com:+]; DMARC_NA(0.00)[rabson.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[dfr]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pkgbase@freebsd.org]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000006594f805ec7fc45a Content-Type: text/plain; charset="UTF-8" On Wed, 2 Nov 2022 at 16:48, Kyle Evans wrote: > On Wed, Nov 2, 2022 at 11:35 AM Doug Rabson wrote: > > > > > > > > On Wed, 2 Nov 2022 at 16:30, Kyle Evans wrote: > >> > >> On Wed, Nov 2, 2022 at 11:21 AM Doug Rabson wrote: > >> > > >> > > >> > > >> > On Wed, 2 Nov 2022 at 16:07, Guido Falsi wrote: > >> >> > >> >> On 02/11/22 16:32, Doug Rabson wrote: > >> >> > > >> >> > > >> >> > On Wed, 2 Nov 2022 at 13:54, Guido Falsi >> >> > > 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 ? > >> >> > > >> >> > > >> >> > >> >> > >> >> 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 :( --0000000000006594f805ec7fc45a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, 2 Nov 2022 at 16:48, Kyle Eva= ns <kevans@freebsd.org> wro= te:
On Wed, Nov 2, 2022 at 11:35 AM Doug Rabson &= lt;dfr@rabson.org&g= t; 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:
>> >> >
>> >> >=C2=A0 =C2=A0 =C2=A0Hi!
>> >> >
>> >> >=C2=A0 =C2=A0 =C2=A0I am trying to upgrade head using= packaged base and I'm getting this
>> >> >=C2=A0 =C2=A0 =C2=A0error now:
>> >> >
>> >> >=C2=A0 =C2=A0 =C2=A0pkg: FreeBSD-runtime-dev-14.snap2= 0221102095743 conflicts with
>> >> >=C2=A0 =C2=A0 =C2=A0FreeBSD-runtime-14.snap2022110209= 5743 (installs files into the same
>> >> >=C2=A0 =C2=A0 =C2=A0place).=C2=A0 Problematic file: /= usr/include/dev/wg/if_wg.h
>> >> >
>> >> >=C2=A0 =C2=A0 =C2=A0Looks like for some reason if_wg.= h ended up in both packages.
>> >> >
>> >> >=C2=A0 =C2=A0 =C2=A0Am I doing something wrong and ca= n I work around this or should this be
>> >> >=C2=A0 =C2=A0 =C2=A0fixed 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=3Dpackage=3Druntime,dev and one with tags=3Dpac= kage=3Druntime. Can you open
>> >> > a bug on bugs.freebsd.org <http://bugs.freebsd.or= g>?
>> >> >
>> >> >
>> >>
>> >>
>> >> sure!
>> >
>> >
>> > I think the problem is caused by the 'copies' target = in src/include which is where the second metalog entry happens. From my lim= ited understanding, this target shouldn't create metalog entries but I&= #39;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 th= ose, but
>> that's wrong on a number of levels. All of the headers need, a= t 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 g= roup 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 y= ou have time to work on? I am very far from understanding how this stuff wo= rks :(

--0000000000006594f805ec7fc45a--