From nobody Wed Aug 6 22:22:09 2025 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 4by4Xz1xDGz64JLd for ; Wed, 06 Aug 2025 22:22:27 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4by4Xy29btz3TWh; Wed, 06 Aug 2025 22:22:26 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-af910372ab3so253998666b.1; Wed, 06 Aug 2025 15:22:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754518942; x=1755123742; 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=zBwIaNjph900wt3+p7XgACIujPkhWzEgxJA6DiCExFE=; b=eh7vtw389xKWjbvenPXcCBSZ3lJjc8F3+YLStKlLnPmLAMsF0gDvmrlJnmosFXvyXJ hJe1oS8J0ZFL+HUrhM7bUTTftLPJRDn7N/bIoylzHr29HkIgk5WOv1u0/Go8TpRpWnof oATgkdCb3Hwi7PrivSyq2jiO6h/DBC+rrozOfV+MD9XbjrtiQU5RxLD7RO1siG3+yLfa r2Dbvws7mOBojauHCkIwh1iIswkJdoi66BX8vZFr1GcIwdBfFeF2iNXnyip/M6Utjowa l2EWuLAnuGU+8RSRX0pQyznZbsIGxqrzXoJW7Xtlsx8h7MEeBmSQ/cmANGPu14i5gqBV FLtg== X-Gm-Message-State: AOJu0Yx0f0rWyUcid/IzY/mUEJRYwJMjV/9RlkeqYJxR2IkVNbBT+K6l LBYf7UsL4cELnJaaU3drjh6h9+XEYsPixg899bQVfvgHZqJLtX5TIWc3H6LFXGI6nr31ZqTy3bM BriSfSfuydLc+b3Z/1lx9/PJ+MaUcD1ikLw== X-Gm-Gg: ASbGncuOE1Y+zw4XVnOu8SPwLw5JnExLqhbR940D276vVVHVT2aHkTeep94tMxYhJDg NzeSpk4HSy4j+Yp5n6Lru2GRe97sLmLsPGfTpDFa8mjyKLdD1iaoVaGteqXfAAOc3xC1qOepaQI 6FuxExSAwpc6WiiDXMOa9I4amF1Cfmf3hA4LvlkM5Sp4WJfJlLrJZ5SO+42MsZx5o4Q7cRqanpv q9NP1c= X-Google-Smtp-Source: AGHT+IHQePb+jvibeFEMVZigBwz9fXTTUGWamS4DBJ5XAQ+mU2uofRyv6qbNG6TC/rP0kQJHoA+47F0DBxyjgMcXZwI= X-Received: by 2002:a17:907:97cc:b0:af9:41a4:25b3 with SMTP id a640c23a62f3a-af9a3ee84f6mr104484166b.29.1754518941719; Wed, 06 Aug 2025 15:22:21 -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: Alan Somers Date: Wed, 6 Aug 2025 16:22:09 -0600 X-Gm-Features: Ac12FXxEdyaTduRWElism8vO5cwWAWH5aFjrUesHqujx46sHJLocSBiritWTc2s Message-ID: Subject: Re: freebsd-update and pkgbase To: Mark Johnston Cc: freebsd-pkgbase@freebsd.org Content-Type: multipart/alternative; boundary="00000000000045e242063bb9c6dc" X-Rspamd-Queue-Id: 4by4Xy29btz3TWh X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] --00000000000045e242063bb9c6dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 6, 2025 at 3:17=E2=80=AFPM Mark Johnston wr= ote: > The future of freebsd-update post 15.0 isn't totally clear. There have > been proposals to remove it in 15.0. IMO we can't remove it outright, > since may be needed in order to upgrade 13.x and 14.x jails on a 15.0 > host. It is also a shame to lose a simple upgrade utility that is > well-documented and that many users are familiar with; compare > "freebsd-update upgrade -r 14.3-RELEASE" with the upgrade instructions > on the pkgbase wiki page. > > pkgbase offers a lot of flexibility but I suspect many users don't need > it; they need a one-shot "upgrade my system, please" utility that will > automatically create a boot environment, configure pkg repositories as > needed for major/minor/security upgrades, fetch packages, and handle > package installation order (i.e., kernel first, followed by a reboot). > > I don't really think this functionality belongs in pkg itself. So, > seeing as freebsd-update already handles some of the above, and users > are already familiar with it, I propose extending freebsd-update to work > in a pkgbase world. Users would be free to not use it and instead use > pkg directly if they so desire, but this would provide a simple > alternative to those who don't want or need that flexibility. > > I'm going to try implementing this, if only to see if there are any > unexpected issues that come up. Feedback would be appreciated, both on > the proposal itself and on any technical hurdles you see. Aside from > the internal changes needed to make freebsd-update subcommands use pkg, > I see a few tasks and requirements: > - freebsd-update should be able to bootstrap pkgbase; in practice, I > think this means that we should import pkgbaseify and make > freebsd-update able to run it if the user so requests. > - freebsd-update should possibly live in its own pkgbase package so that > it can upgrade itself before the rest of the system. > - freebsd-update should configure a pkgbase repository using a file in > /etc/pkg, disabled by default so that regular "pkg upgrade" doesn't > try to touch the base system. I'm not sure yet how repository > configurations should be managed: should they be dynamically > generated, or should we provide some bundle of configurations (e.g., > one for every supported release), or? > - We need to figure out how to handle freebsd-update.conf options which > don't make sense in a pkgbase world. > This sounds like a great idea. You might consider switching to freebsd-rustdate, though. It's far faster and somewhat easier to use. It's probably more maintainable, too. --00000000000045e242063bb9c6dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 6, 2025 at 3:17=E2=80=AFPM Mark J= ohnston <markj@freebsd.org> = wrote:
The futur= e of freebsd-update post 15.0 isn't totally clear.=C2=A0 There have
been proposals to remove it in 15.0.=C2=A0 IMO we can't remove it outri= ght,
since may be needed in order to upgrade 13.x and 14.x jails on a 15.0
host.=C2=A0 It is also a shame to lose a simple upgrade utility that is
well-documented and that many users are familiar with; compare
"freebsd-update upgrade -r 14.3-RELEASE" with the upgrade instruc= tions
on the pkgbase wiki page.

pkgbase offers a lot of flexibility but I suspect many users don't need=
it; they need a one-shot "upgrade my system, please" utility that= will
automatically create a boot environment, configure pkg repositories as
needed for major/minor/security upgrades, fetch packages, and handle
package installation order (i.e., kernel first, followed by a reboot).

I don't really think this functionality belongs in pkg itself.=C2=A0 So= ,
seeing as freebsd-update already handles some of the above, and users
are already familiar with it, I propose extending freebsd-update to work in a pkgbase world.=C2=A0 Users would be free to not use it and instead use=
pkg directly if they so desire, but this would provide a simple
alternative to those who don't want or need that flexibility.

I'm going to try implementing this, if only to see if there are any
unexpected issues that come up.=C2=A0 Feedback would be appreciated, both o= n
the proposal itself and on any technical hurdles you see.=C2=A0 Aside from<= br> the internal changes needed to make freebsd-update subcommands use pkg,
I see a few tasks and requirements:
- freebsd-update should be able to bootstrap pkgbase; in practice, I
=C2=A0 think this means that we should import pkgbaseify and make
=C2=A0 freebsd-update able to run it if the user so requests.
- freebsd-update should possibly live in its own pkgbase package so that =C2=A0 it can upgrade itself before the rest of the system.
- freebsd-update should configure a pkgbase repository using a file in
=C2=A0 /etc/pkg, disabled by default so that regular "pkg upgrade"= ; doesn't
=C2=A0 try to touch the base system.=C2=A0 I'm not sure yet how reposit= ory
=C2=A0 configurations should be managed: should they be dynamically
=C2=A0 generated, or should we provide some bundle of configurations (e.g.,=
=C2=A0 one for every supported release), or?
- We need to figure out how to handle freebsd-update.conf options which
=C2=A0 don't make sense in a pkgbase world.

This sounds like a great idea.=C2=A0 You might consider switching = to freebsd-rustdate, though.=C2=A0 It's far faster and somewhat easier = to use.=C2=A0 It's probably more maintainable, too.=C2=A0
--00000000000045e242063bb9c6dc--