Multiple issues trying to package COSMIC DE components

[fsvm88]

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:

1. 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)
2. 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)
3. 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:

1. 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.
2. 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?

[mgorny]

Workspace packages should just work, you just need to pass all directories you need.

As for the rest, that sounds like cargo.eclass limitations.

[fsvm88]

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).