I mean, it's not a full implementation because it only handles building,
signing and parsing packages (not rpmdb management or specfile parsing or
anything else), but, it kind of already exists
https://github.com/rpm-rs/rpm
--
Reply to this email directly or view it on GitHub:
And we're live now with
https://github.com/rpm-software-management/rpm/pull/3028 :partying_face:
For the morbidly curious, there was certainly more to clean up before that, the
major preparatory work being in
https://github.com/rpm-software-management/rpm/pull/2977,
Yeah, I've always been afraid of broaching the idea seriously. I had joked
about this with @ffesti a few times at the openSUSE Conference, but I'm really
glad to see us doing this.
--
Reply to this email directly or view it on GitHub:
Nice to see somebody besides ourselves being excited about this :smile:
And yeah that is really a big part of the point: rpm's data structures aren't
really that exotic, but to someone new it's all lost in the details of this
specific implementation, and then we have like three different
For what it's worth, I'm excited about the transition to C++, because as a C++
programmer, I feel much more comfortable working my way through and cleaning
things up leveraging the things I know well. So I'm looking forward to this!
--
Reply to this email directly or view it on GitHub:
> As such, moving to C++ now will probably make it harder to move to Rust later.
Well, maybe. My original comment here remember was about how we very
intentionally moved rpm-ostree to "C compiling as C++" explicitly to bridge
with cxx.rs. This...kind of worked in some ways, and definitely
Got it. My comment was meant to be constructive. I'm sorry if it didn't come
across that way.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2983#discussioncomment-8878520
You are receiving this because you are subscribed to
Let me put it this way: if there was a will to move to Rust, maybe sitting out
a few more years waiting for technical matters to sort themselves would be a
meaningful option. That's just not the case.
--
Reply to this email directly or view it on GitHub:
If somebody wants to rewrite rpm from scratch in Rust in another 15 years when
I'm retired, be my guest.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2983#discussioncomment-8877799
You are receiving this because you are
I understand that rpm is not ready for Rust *today*. But I wonder if rpm will
be ready for Rust in 3 or 4 years.
In particular, the Rust ecosystem is quickly becoming a fundamental dependency.
For instance, [Rust is already used in the Linux
kernel](https://lwn.net/Articles/914458/). So
There was plenty enough surrounding rpm-sequoia.
Rust is not an option, that is not up to discussion.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2983#discussioncomment-8877589
You are receiving this because you are
> For starters, it's a show-stopper as a bootstrapping dependency for something
> as early in that chain as rpm.
(Threading this) do you have a link to these discussions? There's a *ton* of
work on bootstrapping Rust (and systems in general) on self-hosting
OSes/distributions. The [GUIX
As for exceptions: rpm's allocator has the terminate-on-failure behavior, which
in practise means any call to the rpm API could abruptly terminate your
process. Which is not a whole lot different from -fno-exceptions.
--
Reply to this email directly or view it on GitHub:
Yes, people keep bringing up Rust. It's just not a viable option for rpm, for a
multitude of reasons. For starters, it's a show-stopper as a bootstrapping
dependency for something as early in that chain as rpm. I won't go further
because it'd be pointless because of that first reason.
--
I have some experience with this; we did a similar thing in rpm-ostree starting
around https://github.com/coreos/rpm-ostree/pull/2336#issuecomment-739556744
The rationale there was actually to aid porting to Rust, because we could use
https://cxx.rs/
There were a lot of things there, see
Ever since the RPM upstream reboot in 2006, we've been striving to replace the
old-school, hand-written pointer gymnastics with general purpose APIs in the
codebase. We've come a long way, but all this time we've been dreaming about
richer data structures than C has to offer. Of course in C,
16 matches
Mail list logo
