Re: greetd+wlgreet packaging and maybe joining the team
On April 27, 2022 11:46 am, Marc Dequènes (duck) wrote:
> Quack,
>
> [...]
>
> In the case of greetd and wlgreet they are not on crates.io. greetd
> embedded the `inish` crate that is internal and `greetd_ipc` that is
> meant to be used by greeters and is published on crates.io. Which leads
> me to a few questions:
> - should I ask upstream to publish them? what do I do if he refuses?
> Is it ok to maintain a debcargo-less package? if so is there any example
> you could refer me to?
ideally they'd publish, yes. there are some packages (e.g., where only
some part is written in rust) that just B-D on librust-foo-dev and use
dh_cargo to setup the build env.
anything packaged in debcargo-conf obviously should use debcargo ;)
> - what do you do with inner crates that the author surely does not
> want to publish separately? does debcargo handle private crates?
there is some support for packaging non-published / local crates, but
AFAIK nothing in Debian uses that (and it would probably need to happen
outside of the rust-* / librust-* namespace, since otherwise something
else in the future could use the crate name on crates.io). debcargo
has the namespaces hardcoded atm, but that would probably not be too
hard to change / make configurable, although it quickly becomes
cumbersome to differentiate dependencies on published crates and
internal ones with different namespaces I guess.
note that debcargo can only do 1 crate == 1 source package == X binary
packages, so you'd still need to package each of those internal crates
on their own.
> - can debcargo handle rust-greetd src that would produce both greetd
> and librust-greetd-ipc-dev binaries?
in your case, you'd have src:rust-greetd producing bin:greetd and
src:rust-greetd-ipc producing bin:librust-greetd-ipc-dev, with
src:rust-greetd build-depending on bin:librust-greetd-ipc-dev
> The policy page on the wiki did help me understand the general rules but
> I did not find anything about the "not in crates.io' situation.
we usually try to convince upstreams to publish their stuff, or drop
internal crates if they are not strictly needed for building (e.g., if
they are dev-deps used for testing). if everything fails, packaging what
is published in debcargo-conf and then the leaf (binary) package +
whatever is left internal outside of debcargo-conf as a last resort is
an option of course.
Reply to: