tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: $ORIGIN in RPATH suppression
Martin Husemann <martin%duskware.de@localhost> writes:
> On Thu, Jan 02, 2025 at 05:29:23PM +0000, pin wrote:
>> I've commited nearly 1000 packages during 2024, most of it Rust
>> things + LXQt (twice). I'm already holding two or three updates that
>> require either 1.82 or, 1.83 to build.
>
> I wonder if we should have a policy that such pkgs should only go in
> pkgsrc (instead of wip) if the required rust version is at least a year
> old or they are special developement pkgs (like ${something}-git where
> we also have a stable/sane ${something} pkg).
>
> And we should file upstream bug reports if this happens and stops pkgs
> from being updated.
I don't understand where you are coming from. If a package needs at
least version X of some dependency (be it rust or something else), and
pkgsrc has >= X, then there is no problem for pkgsrc. How old the rust
version is doesn't really matter, once it's in pkgsrc.
(This assumes that pkgsrc has a single rust version, and that it works
on all os/version/cpu combinations where we claim rust works at all.)
It's certainly an upstream bug to require super-recent versions of
dependencies, unless there is a really good reason and avoiding such
would be significantly difficult. It's also a bug to require a specific
rust compiler version, rather than a language specification. But
upstreams that use rust tend to think this is ok, and while I'm
philosophically in agreement that filing bugs makes sense, it seems
unlikely to be productive.
(My general rule of thumb is that a program released on D should be ok
with any version of a dependency that was current at any point from D-2y
to D. And that exceptions should be relatively rare and have a good
reason.)
Home |
Main Index |
Thread Index |
Old Index