Hi folks,
I'm still working on updating Taskwarrior to version 3, which is a complete rewrite in Rust. A WIP PR is here:
https://src.fedoraproject.org/rpms/task/pull-request/3
Unfortunately with the newer releases, the number of deps has increased quite a bit, primarily for the main "storage" library, taskchampion. This is the list I've got (so far):
https://hackmd.io/@sanjayankur31/SJZWmHb9Jl
I'm going to work through them one by one. A few of these were already packaged but retired, so I'll un-retire them and take them on too.
I just thought I'd let everyone know so these new packages don't come as a surprise. (If you find any of the deps useful too, please feel free to package them and/or review my package review tickets---I won't stop you ;))
I do see that in some cases crates depend on specific versions of other crates, but these are often different from the version we have in Fedora. Is the right thing to do patch the version to match what we have in Fedora (when using rust2rpm)? Or should one package the exact version as a compat package and so on? (I'm afraid my rust skills aren't good enough to update crates and send patches upstream, and I wouldn't be able to do this for a large number of packages.)
On Fri, Feb 21, 2025 at 12:44 PM Ankur Sinha via Rust rust@lists.fedoraproject.org wrote:
Hi folks,
I'm still working on updating Taskwarrior to version 3, which is a complete rewrite in Rust. A WIP PR is here:
https://src.fedoraproject.org/rpms/task/pull-request/3
Unfortunately with the newer releases, the number of deps has increased quite a bit, primarily for the main "storage" library, taskchampion. This is the list I've got (so far):
Hm, this indeed looks like a lot. But I suspect that you might be able to trim the dependency tree to make it more manageable. For example, the whole subtree under "criterion" is a red herring, it's a benchmarking library that can be dropped as a dependency without problems.
I also suspect that the whole aws-* subtree could be pruned, because you might not need the full feature set.
I'm going to work through them one by one. A few of these were already packaged but retired, so I'll un-retire them and take them on too.
If you're referring to the subtree involving criterion, see above :)
I just thought I'd let everyone know so these new packages don't come as a surprise. (If you find any of the deps useful too, please feel free to package them and/or review my package review tickets---I won't stop you ;))
I do see that in some cases crates depend on specific versions of other crates, but these are often different from the version we have in Fedora. Is the right thing to do patch the version to match what we have in Fedora (when using rust2rpm)? Or should one package the exact version as a compat package and so on? (I'm afraid my rust skills aren't good enough to update crates and send patches upstream, and I wouldn't be able to do this for a large number of packages.)
As is so often the case, the answer is "it depends".
If you're confident that the version in Fedora would be compatible with the version specified in the package you're working on, then patching to allow both versions makes sense, as it makes a compat package unnecessary.
However, especially when versions include behaviour changes in addition to API changes, this might not be possible (or at least easy), and in that case we would add a compat package so both versions can be available. I understand that this is no easy task for a "newcomer" to Rust, so when in doubt, just ask when you encounter a specific case like this :)
Fabio
Hi all,
Apologies for the late reply. I was working on a bunch of neuro-sig packages that needed fixing.
On Fri, Feb 21, 2025 12:50:28 +0100, Fabio Valentini wrote:
On Fri, Feb 21, 2025 at 12:44 PM Ankur Sinha via Rust
<snip> > https://hackmd.io/@sanjayankur31/SJZWmHb9Jl
Hm, this indeed looks like a lot. But I suspect that you might be able to trim the dependency tree to make it more manageable. For example, the whole subtree under "criterion" is a red herring, it's a benchmarking library that can be dropped as a dependency without problems.
Ah! Thanks for that. That does chop off a quite a few deps.
I also suspect that the whole aws-* subtree could be pruned, because you might not need the full feature set.
Yeh, thing is I don't know enough about the taskchampion code base to know what features it does need. I'll try to go through it and figure this out. A lot of them seem to be dependencies of aws-config, so would it be OK to patch out stuff from aws-config that taskchampion doesn't use? (Won't that mean that the aws-config package itself is "incomplete"?)
I'm going to work through them one by one. A few of these were already packaged but retired, so I'll un-retire them and take them on too.
If you're referring to the subtree involving criterion, see above :)
<snip>
I do see that in some cases crates depend on specific versions of other crates, but these are often different from the version we have in Fedora. Is the right thing to do patch the version to match what we have in Fedora (when using rust2rpm)? Or should one package the exact version as a compat package and so on? (I'm afraid my rust skills aren't good enough to update crates and send patches upstream, and I wouldn't be able to do this for a large number of packages.)
As is so often the case, the answer is "it depends".
If you're confident that the version in Fedora would be compatible with the version specified in the package you're working on, then patching to allow both versions makes sense, as it makes a compat package unnecessary.
Would checking that the package builds and all tests pass be sufficient to make this decision? I supposed it depends on how good the tests are, though, so ideally one needs to know enough about the code base to make an informed decision..
However, especially when versions include behaviour changes in addition to API changes, this might not be possible (or at least easy), and in that case we would add a compat package so both versions can be available. I understand that this is no easy task for a "newcomer" to Rust, so when in doubt, just ask when you encounter a specific case like this :)
Thank you, I'll do that.
I'll go patch out criterion and submit the next round of reviews.
On Tue, Mar 4, 2025 at 1:25 PM Ankur Sinha via Rust rust@lists.fedoraproject.org wrote:
I also suspect that the whole aws-* subtree could be pruned, because you might not need the full feature set.
Yeh, thing is I don't know enough about the taskchampion code base to know what features it does need. I'll try to go through it and figure this out. A lot of them seem to be dependencies of aws-config, so would it be OK to patch out stuff from aws-config that taskchampion doesn't use? (Won't that mean that the aws-config package itself is "incomplete"?)
You shouldn't need to look at the actual *code*. What I meant is looking at the other side of that coin: Disabling optional features that are actually not needed. That will make the package only "incomplete" in the same sense as Python packages that don't have all possible +extra subpackages :)
If you're confident that the version in Fedora would be compatible with the version specified in the package you're working on, then patching to allow both versions makes sense, as it makes a compat package unnecessary.
Would checking that the package builds and all tests pass be sufficient to make this decision? I supposed it depends on how good the tests are, though, so ideally one needs to know enough about the code base to make an informed decision..
Yeah, this depends on how good test coverage is. I usually look at the release notes for the library - if there are only API changes but no behaviour changes, then if things keep compiling and testing successfully, everything should be fine. If the release notes mention behaviour changes that are not expressed in API changes, then I am more careful and usually provide both the old and the new version of the library.
Fabio