> it would be useful to clamp the ownership of the files to root:root--though
> this will necessitate ensuring that the applications which work with RPM
> input/output respect this clamping and change the permissions if a user
> extracts or installs it. (Namely, we don't want a user to install
> > None of this is inherently Linux specific, however to make it reasonably
> > fast and efficient, you need something like OverlayFS which is currently
> > only available on Linux (and [#2559
> > (comment)](https://github.com/rpm-software-management/rpm/pull/2559#issuecomment-165921)
> >
> I will also point out there are openSUSE containers that use DNF too.
Interesting, thanks for sharing. I don't think it changes anything discussed
here so far, though :smile:
--
Reply to this email directly or view it on GitHub:
> None of this is inherently Linux specific, however to make it reasonably fast
> and efficient, you need something like OverlayFS which is currently only
> available on Linux (and
> https://github.com/rpm-software-management/rpm/pull/2559#issuecomment-165921
> on some BSDs through
One more thing to add to the above: *This* ticket is about using OCI images for
the test root creation, on Linux distributions. Any kind of non-Linux work
would need to be tracked in a separate ticket.
--
Reply to this email directly or view it on GitHub:
> Keep in mind, we need a way to run it directly on the host, because all this
> fanciness you're talking about doesn't exist on non-Linux platforms. In
> particular, I would like to be able to run the test suite for RPM on macOS
> still.
In essence, what the test-suite needs is a filesystem
I'd really prefer that we merge the existing certificate with the new
certificate. This is particularly important as gpg strips old self signatures
when exporting certificates. One consequence of replacing an existing
certificate with a new version is that existing packages may not verify
As per
https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1719074225
:
> trying to shoehorn the keys into something resembling a package has been a
> major source of headache as long as it's been there. It's just difficult to
> get rid of. Ideally this would all happen in
Also, the way the keys are handled as sort of packages, people probably
wouldn't be too shocked if we just treated it as a simple upgrade (erase old,
import new) based on timestamp, and not worry about any merging at all.
--
Reply to this email directly or view it on GitHub:
Yup, trying to shoehorn the keys into something resembling a package has been a
major source of headache as long as it's been there. It's just difficult to get
rid of. Ideally this would all happen in some blackbox keyring and rpm doesn't
need to care.
As long as we're stuck with the
Ok, thanks for the clarification.
>From my perspective, there is no way to generate a version number for an
>OpenPGP certificate. This is because an OpenPGP certificate is composed of
>packets, and packets can be left out without making the certificate completely
>invalid. This is exactly
This is as good as any, I just wanted to point out to the reporter that
whatever and whenever happens here can only be a forward-going solution, Google
will need to deal with their existing users by some other means.
--
Reply to this email directly or view it on GitHub:
This is actually a subcase of #446, closing.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1344#issuecomment-1718921839
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #1344 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1344#event-10368445792
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
This is the major part of what is needed for #1240
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2646#issuecomment-1718917225
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #1786 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1786#event-10368279514
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
The PR died of old age, presumably this can be closed too then.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1786#issuecomment-1718902209
You are receiving this because you are subscribed to this thread.
Message ID:
Indeed, storing the local user/group into src.rpm makes no sense whatsoever.
It's an anachronism from the ancient days before Buildroot was a thing that has
somehow survived all the way up to this date. We've made some effort to swipe
the symptoms under the carpet (ie avoid pointless warnings
@pmatilai, unfortunately, I think you're right. Where should we discuss how to
implement the merge / update operation?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2577#issuecomment-1718855631
You are receiving this because you are
I think we already decided. What remains is documenting it.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2477#issuecomment-1718851964
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #1226 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1226#event-10367580769
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
This needs to be considered as part of #329 rather than a separate item.
Closing now that it's linked.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1226#issuecomment-1718821511
You are receiving this because you are subscribed to
22 matches
Mail list logo
