Path: csiph.com!fu-berlin.de!bofh.it!news.nic.it!robomod From: Miguel Ojeda Newsgroups: linux.debian.kernel Subject: Re: Rust for Linux and host-only libraries Date: Sat, 20 Apr 2024 12:40:01 +0200 Message-ID: References: X-Original-To: debian@fabian.gruenbichler.email X-Mailbox-Line: From debian-kernel-request@lists.debian.org Sat Apr 20 10:36:13 2024 Old-Return-Path: X-Amavis-Spam-Status: No, score=-2.199 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no X-Policyd-Weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 CL_IP_EQ_HELO_IP=-2 (check from: .gmail. - helo: .mail-pl1-x62a.google. - helo-domain: .google.) FROM/MX_MATCHES_HELO(DOMAIN)=-2; rate: -5.5 X-Forwarded-Encrypted: i=1; AJvYcCUbiLD8g+yA9diOUCVTDVbiY7fKA3mbftZYyYnKBCXEn/t7XDfv/jQBD+K86FA6ppawqJW8uSxviExWO9gimQ5w8RrmKb4xJGw08iz/9lk= X-Gm-Message-State: AOJu0YygXJZSNqguauAHwF5UxT0eZSc6K7nr9dAPEeBV5DkF0Hbx+UQ8 mluOBiiXByoW8HUOeLdm8Yoc1/SZZwKVCo4i8h7MyJre3HBE8RTH2J5x9Qp48UM/eLLx1dANVbS rR5SB2F8tkZPtb+8QH0Un/bc8L27puNKx X-Google-SMTP-Source: AGHT+IH4hU8Sc/YHCXtRiQYxF4P9HRrC5dLuTzb/VcAa3WF7xc8wCTXiAax5vSsNQF9cekv4d/xDEQ3CuCzJi6y8l+k= X-Received: by 2002:a17:902:e84a:b0:1e4:48e7:3dab with SMTP id t10-20020a170902e84a00b001e448e73dabmr6822289plg.38.1713608421982; Sat, 20 Apr 2024 03:20:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailing-List: archive/latest/142396 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/CANiq72n+S44dbkK4BM1myqJV1x-cvFReDO7e7=3Zy2hpR1oFJA@mail.gmail.com Approved: robomod@news.nic.it Lines: 77 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Cc: infinity0@debian.org, sylvestre@debian.org, pkg-rust-maintainers@alioth-lists.debian.net, debian-kernel@lists.debian.org X-Original-Date: Sat, 20 Apr 2024 12:19:17 +0200 X-Original-Message-ID: X-Original-References: <24AABC3E-9729-4E93-B2D2-B9CFBEB0DF71@fabian.gruenbichler.email> <8EB6C41A-DEA9-4665-855A-644DE401F68D@fabian.gruenbichler.email> Xref: csiph.com linux.debian.kernel:82277 On Fri, Apr 19, 2024 at 10:34=E2=80=AFPM Fabian Gr=C3=BCnbichler wrote: > > No, the patches are already applied in the source files shipped by librus= t-xxx-dev, if there are any. The cargo wrapper takes care of other things, = like instructing cargo to use the packaged sources and setting rustflags an= d similar options. You should be able to use the same sources with manual r= ustc invocations without cargo or our wrapper just fine :) Great, that should make it straightforward then :) > There's a bit of peculiarity around the versioning - the librust-.. packa= ges provide all the semver prefixes of their version as well, so you can ex= press "I want crate X in a semver compatible version of at least 2.3" via a= versioned dependency (by depending on librust-x-2-dev with a version of at= least 2.3), but also the more restricted variants (e.g., X in some 2.3.n v= ersion, or a specific 2.3.4 version, by depending on librust-2.3-dev resp. = librust-2.3.4-dev). Normally, the actual package providing all of those is = librust-X-dev, except when we need to package more than one version of X, t= hen there might be a librust-X-dev in version A (providing all the semver p= refixes of A), and another package librust-X-B-dev, where B is the shortest= semver-breaking prefix of a semver incompatible version older than A (prov= iding all semver prefixes of that version). A might be 2.3.4 and B 1 (with = B's full version being 1.2.0, for example). Most of that won't be relevant = for you - except that you want to depend on e.g. librust-syn-1-dev if you w= ant syn 1.x, even if the actual "real" package is called librust-syn-dev, a= s the latter might also contain syn 0.x or 2.x in other distros/releases. H= ope this was not too confusing ;) That is good to know, thanks! So, ideally, we would avoid handling versioning/packaging as much as possible, i.e. making it as independent of distributions and so on as possible, and letting the user install the packages themselves. It should be possible to just pass a path to a random folder with the library, if needed. So ideally we would suggest in the instructions what packages to install (for major distributions), and try to be agnostic otherwise in the actual build system. That implies that the question is trying to automate, if possible, finding the sources, without hardcoding too much information. For instance, one naive way would be just testing whether any `/usr/share/cargo/registry/{library}-{major}*` folder exists and use the highest one if so. If people only have a single version installed (per major) or if the dependencies' constraints are relaxed/compatible enough, that could "just work". Is that way too naive? Because even if it is naive, but works for most kernel developers out there, that may be good enough. And if it fails, one can always customize the paths as needed. The problem, of course, is cases where silent miscompilations could occur. For instance, Debian or another distribution could provide two minors (of the same major version) of library A there, and then library B depends on the lower of the two (for some reason, including possibly a patch you may apply). And it turns out that if one picks the highest A, things actually compile fine, but may behave badly in some cases. Thus we could get, silently, a bad build. I mean, such a sequence of events may be unlikely to happen in practice, especially given the kind of library we are considering using (so far). But still, probably we should just get the paths for the dependencies somehow (e.g. querying Cargo, to avoid parsing `Cargo.toml` ourselves, especially the version constraints; or perhaps there is a better way you can think of) if we want to use the libraries available at `/usr/share/cargo/registry/`. I checked the Debian package, and there were two promising `.cargo-*.json` files, but they do not give information about paths. What do you think? Is there a proper/better/simpler way, for distributions that use `/usr/share/cargo/registry`, to get the paths of a library and its dependencies of a given library? Thanks! Cheers, Miguel