From nobody Wed Sep 04 05:56:09 2024 X-Original-To: freebsd-hackers@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 4WzBbH4hm9z5V9hk for ; Wed, 04 Sep 2024 05:57:15 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WzBbH1hNvz43lr; Wed, 4 Sep 2024 05:57:15 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1725429433; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=L7X9HNBzeff2BQVgXUe6iYRTmH0vWSdsUxJimVrqIDw=; b=r28AeMHgVp3pUrjItPdkY5z2b9XEEfXMswHzAuGrWmyH9pSBhDPptE+Xaad8ffvJhZMrY5 1DsqTsDN3cpZwHHL/C7LkmFiPvMWp13kk/76pKoat6OXnyB61Df8p4xxQH39QDXXZmdxgR 443137L8/Oa9L8u7D5lRuYJgwEAUrOc= Received: from skull.home.blih.net (lfbn-lyo-1-2174-135.w90-66.abo.wanadoo.fr [90.66.97.135]) by mx.blih.net (OpenSMTPD) with ESMTPSA id e105c83e (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 4 Sep 2024 05:57:13 +0000 (UTC) Date: Wed, 4 Sep 2024 07:56:09 +0200 From: Emmanuel Vadot To: Warner Losh Cc: Alan Somers , Poul-Henning Kamp , FreeBSD Hackers Subject: Re: It's not Rust, it's FreeBSD (and LLVM) Message-Id: <20240904075609.a07ee81552928a0ecea273cd@bidouilliste.com> In-Reply-To: References: <202409031532.483FW0If007252@critter.freebsd.dk> <202409031950.483JoBuh009465@critter.freebsd.dk> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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:12876, ipnet:212.83.128.0/19, country:FR] X-Rspamd-Queue-Id: 4WzBbH1hNvz43lr Hi Warner, On Tue, 3 Sep 2024 17:07:53 -0600 Warner Losh wrote: > On Tue, Sep 3, 2024 at 2:40?PM Alan Somers wrote: >=20 > > On Tue, Sep 3, 2024 at 2:21?PM Warner Losh wrote: > > > > > > > > > > > > On Tue, Sep 3, 2024, 2:19?PM Alan Somers wrote: > > >> > > >> On Tue, Sep 3, 2024 at 1:50?PM Poul-Henning Kamp > > wrote: > > >> > > > >> > -------- > > >> > Alan Somers writes: > > >> > > > >> > > For example, libifconfig and the /dev/cam/ctl ioctls are both > > unstable. > > >> > > A port that uses one of those and is built for FreeBSD 14.0 won't > > >> > > necessarily work for 14.1. > > >> > > > >> > Isn't that also a problem today ? > > >> > > > >> > What difference does it make that src is distributed as a package ? > > >> > > >> Not "a package" but "many packages". The pkgbase concept builds a > > >> separate package for almost every dir under lib, bin, sbin, usr.bin, > > >> and usr.sbin. So the problem will be that libifconfig and its > > >> consumers will be distributed separately, whereas they are currently > > >> distributed together. > > > > > > > > > Won't versions and dependencies solve this? They aren't tied to a ker= nel > > version since its a stable ABI. > > > > > > Warnrr > > >> > > >> -Alan > > > > Aren't you the one who just said that the ABI will need to become > > stable? Or did you only mean that about the /dev/cam/ctl ioctls? For > > private libs, the easiest thing would be if pkgbase could put libs and > > their consumers into the same package. But that might not always be > > possible. > > >=20 > Generally, you're supposed to update all the packages in the system, which > would keep > things from getting cross threaded. >=20 > However, I had thought that 'pkg upgrade libfoo' would upgrade all things > that depended > on libfoo. If the lib is properly versioned it will, pkg records any libs that the package depends on in the shlibs_required table and any libs that the package provides in shlibs_provided. So if the package libfoo provides libfoo.so.9 and it's updated to provides libfoo.so.10 any packages that now requires the .10 version will be updated. > However, it doesn't go 'up' the dependency tree, but just 'down' > for things that libfoo > depends upon. It's one of the fragile things about pkg today used with > ports (though often > it's totally fine, since the ABIs are usually stable)... Not sure I follow here. > I'm not familiar enough with the ctl ioctl to state definitively... > However, it appears, at first blush, > to be fairly stable though. >=20 > Warner --=20 Emmanuel Vadot