[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: rust-*/librust-* arch:any vs. arch:all and cross-compilation support



[dropping personal emails and d-devel@l.d.o - feel free to add back]

Hi Helmut,

Sorry for the very slow response time...

Quoting Helmut Grohne (2023-02-20 19:43:52)
> Hi Jonas,
> 
> On Mon, Feb 20, 2023 at 06:44:23PM +0100, Jonas Smedegaard wrote:
> > I don't see a need for such general rule for all librust-*-dev packages.
> 
> This definitely is a trade-off. Hence I asked about what we should do
> about it.
> 
> > E.g. librust-futures-timer-dev and librust-event-listener-dev has no
> > dependencies so should be safe to distribute as arch-all and marked as
> > m-a:foreign, right?
> 
> Yeah, I mentioned librust-typenum-dev earlier and you found more. I
> expect that there are probably hundreds of pure rust libraries without
> dependencies. Really, the only reason to not have them arch:all is
> mitigating the risk of changing dependency trees.
> 
> > Sure, there is a theoretical risk that some day in the future those
> > packages grow dependencies that require changing that, but isn't that
> > the case generally for m-a hinting?
> 
> You are entirely correct about this. It definitely is a heuristic.
> 
> > I guess it makes sense instead to have a lintian warning for packages
> > marked m-a:foreign that all its dependencies are equally marked (or if
> > that's unreasonably expensive then check only one level deep).  That
> > should help flag misuses of m-a:foreign including this one of mine (for
> > most but not all the librust-*-dev packages that I maintain).
> 
> lintian does not have the full picture. It looks at one source package
> plus all of its binary packages in isolation. It cannot see the
> multi-arch annotations of dependencies. Hence the multi-arch hinter was
> added as an extra component outside lintian. On the flip side, the
> hinter could do the flagging that you suggest here. In essence, it could
> flag all packages satisfying all of the following conditions:
>  * Architecture: all
>  * Multi-Arch: foreign
>  * Package: librust*-dev
>  * Depends: some package that is not m-a:foreign
> 
> We can actually express this in SQL:
> 
> SELECT name
> FROM indeppackage AS i
> WHERE name LIKE 'librust%-dev'
>         AND multiarch = 'foreign'
>         AND EXISTS (SELECT 1 FROM archdepcandidate AS c WHERE c.dependerid = i.id);

Can the above be refined to ignore dependency packages not m-a:foreign
which are named librust-*?

...because as I understand it those pose no problem here, they are just
using bogus hinting for convenience reason.


> Should the hinter generate reverse hints for these and thus issue
> action items on tracker.d.o?

If convenience-hinting packages can be omitted (assuming I correctly
understood the reasoning for doing so), then yes, I would find it
beneficial to have such action item on tracker.d.o.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: signature


Reply to: