You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
cosmic-applets uses a workspace and builds a multicall binary, so it would be hard to justify "change to component and create a separate ebuild for each" -> each ebuild would recompile the same binary multiple times, resulting in N times disk space usage (currently the binary is 72MB with only debug lines info and stripped - current ebuild)
When downloading the crates for cosmic-app-list (applet in cosmic-applets), pycargoebuild aborts due to iced* packages not found in crate libcosmic (the ~kdelibs/~gtk+ of COSMIC), because it downloads libcosmic-4f77edd249e1c9cd525232050cec00c752ce7860.gh.tar.gz, which includes a forked version of iced library as a submodule, which is an empty folder in the snapshot (I hope it goes away as the DE matures and before stable is released)
I cannot use cargo_live_src_unpack and a specific tag without a workaround (see below), because the check for PV==*9999* prevents its use
So, in short: I cannot generate ebuilds with version-locked crates due to 1 and 2 (for any package due to 2), and I cannot use am not supposed to do live fetching due to 3.
I managed to hack my way around all of this by using PV=9999 cargo_live_src_unpack in my eclass, because luckily the function only checks PV and never uses it, but ofc I really don't like it :)
Questions:
Any chance 1) can be improved upon? I don't see the multicall binary approach being reverted in the near future. If not, I guess worst case I could extract CRATES for each component and merge the resulting arrays.
Could it make sense to add a soft-fail option to allow the parsing to continue in case of errors for 2? Perhaps making it clear with an obvious error at the end and non-0 exit code?
The text was updated successfully, but these errors were encountered:
Workspaces -> thanks, I had no idea multiple folders could be supplied, I was looking for it but I didn't find anything in the docs. If you want I can open a PR to mention it explicitly in the README - I saw afterwards that pycargoebuild --help shows ... [directory ...], but I couldn't spot it in the beginning.
3 -> agree, it's a cargo.eclass limitation, I'll probably mention this to the rust maintainers if the packaging from COSMIC side doesn't improve, I don't want to keep abusing PV.
2 -> I read through the code, and as I understand it it's pycargoebuild doing the fetching. Regardless, I guess I'll live with the limitation for now, and will try to ask COSMIC to do the proper thing instead (I expect them to do it regardless in the future).
Hi! I've been packaging COSMIC DE in a dedicated overlay for a while now.
In response to this issue, I tried to package the first tagged release
epoch-1.0.0-alpha.1
.Issues:
cosmic-app-list
(applet incosmic-applets
),pycargoebuild
aborts due toiced*
packages not found in cratelibcosmic
(the ~kdelibs/~gtk+ of COSMIC), because it downloadslibcosmic-4f77edd249e1c9cd525232050cec00c752ce7860.gh.tar.gz
, which includes a forked version oficed
library as a submodule, which is an empty folder in the snapshot (I hope it goes away as the DE matures and before stable is released)cargo_live_src_unpack
and a specific tag without a workaround (see below), because the check forPV==*9999*
prevents its useSo, in short: I cannot generate ebuilds with version-locked crates due to 1 and 2 (for any package due to 2), and I
cannot useam not supposed to do live fetching due to 3.I managed to hack my way around all of this by using
PV=9999 cargo_live_src_unpack
in my eclass, because luckily the function only checks PV and never uses it, but ofc I really don't like it :)Questions:
The text was updated successfully, but these errors were encountered: