Fabio Valentini venit, vidit, dixit 2024-04-04 22:41:19: > On Thu, Apr 4, 2024 at 9:42 PM pfed--- via devel > <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Thu, Apr 04, 2024 at 09:51:31AM +0200, Fabio Valentini wrote: > > > > > The short answer is: No, "fedpkg local" is not expected to work for > > > > > Rust packages, and probably won't ever work as expected for Rust > > > > > packages. > > > > > > > > > > I am not really interested in adding the "--allow-dirty" flag (not > > > > > sure if it would even work in this case), since building Rust packages > > > > > with "fedpkg local" is not working for other reasons. Primarily, > > > > > "fedpkg local" does not support dynamically generated BuildRequires - > > > > > this is only supported when building in mock. > > > > > > > I don't know what you mean? For me after patching the macro locally > > > > local builds work as expected. Maybe I'm overlooking something? > > > > > > You might be lucky and just tried to package a Rust crate with no > > > dependencies? > > > Dependencies on other Rust crates are only resolved dynamically at build > > > time, which "fedpkg local" does not support. So it works "by accident" for > > > Rust crates with no crate dependencies, but in general, it can't work. > > > > That would have been extremely lucky, but no, I'm building crates with > > dependencies. And the build generates the requires list just fine. > > > > What is not possible is installing build dependencies directly from a > > spec file from a fresh clone, if that is what you mean? But in this case > > running a local build generates a `.buildreqs.nosrc.rpm` file with the > > correct dependencies, which can be passed to `dnf builddep`. > > > > And since a local build does not manage build dependencies themselves, > > rather relies on them just being there, I don't really see an issue in > > that? > > If you really don't mind jumping through multiple hoops just because > you want to use "fedpkg local" instead of "fedpkg mockbuild", then I > guess I can't stop you. > > All I *can* do is tell you that you're not going to like the experience: > > - Using "fedpkg local" is not supported for Rust packages, and I won't > be adding workarounds to the Rust macros for it. > - Installing rust-*-devel packages on your local system (i.e. outside > of ephemeral build environments) is not supported. > - The "rust-*-devel" packages are build system implementation details, > if you want to say it like that. > - They are not shipped to users and are not useful for Rust developers. > - They are *only* intended to be installed in temporary chroots (like > those set up by mock). > - They don't get "Obsoletes" or "Provides" in case there are dropped > subpackages and / or incompatible updates. This is not an issue > because they are only ever *installed*, but never supposed to be > *upgraded* in-place. Any issues you get by installing them on your > host system are your own. So you're saying that those packages are in the repos for everyone but not meant to be installed by anyone (besides mock chroots), and that is how and why they are packaged. `This package contains library source intended for building other packages which use the "xyz" crate.` Unless you `fedpkg local` build it. Or maybe only if you `fedpkg mockbuild` it. Does a rebuild from `fedpkg srpm` even work? Wow! Is there any other set of packages which we package like that? If that is how you do things for the rust eco-system, those "devel" packages should be clearly distinguished from real development packages, come with a huge boiler plate "do not install" - or, really, be in a separate repo if installing them is both worthless and misleading for any "real" user. CRB for Fedora material. Michael -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
