Re: EOL and Obsoletes in Modularity
by Neal Gompa
On Thu, Oct 29, 2020 at 8:17 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>
> On 10/29/20 12:43 PM, Petr Pisar wrote:
> >> OTOH If the EOL date is informational only (Anna keeps postgresql:9.5 but
> >> sees a warning during dnf upgrades) and the obsoletes only actually happen
> >> on a specific user action (and on release boundary), great.
> >
> > That's how it is suspposed to work. Read "Proposed dnf behavior" in
> > <https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL>.
>
> Indeed, in that case a mid-release EOL makes sense, sorry for the confusion.
>
Ideally, DNF could have different policy modes for EOLs. By default
it could throw warnings about using EOL content and still let you
install it, but in a mass-managed scenario, the policy could be
switched to enforcing (if you haven't already installed it, you
can't).
--
真実はいつも一つ！/ Always, there's only one truth!
3 years, 7 months
Re: EOL and Obsoletes in Modularity
by Miro Hrončok
On 11/2/20 12:33 PM, Daniel Mach wrote:
> Then there's a question how to get the documents into modules.yaml. From my
> perspective, it's up to Fedora infra/releng/packaging people. Whether it should
> be in dist-git, git repo (similar to modulemd-defaults or comps), PDC, Bodhi
> (similar to updateinfo) or somewhere else - that's entirely their call.
I understand this perspective, but unless we have Fedora infra/releng/packaging
people who would own this and drive this, it won't happen. I consider myself
"packaging people" and I certainly won't. Do we have at least an idea if we have
such people?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 7 months
Re: EOL and Obsoletes in Modularity
by Petr Pisar
On Mon, Nov 02, 2020 at 12:33:23PM +0100, Daniel Mach wrote:
> From DNF team's perspective, a packaging system is not complete without
> Obsoletes. That's why we believe module Obsoletes are a must have to ensure
> smooth system upgrades and regular updates on systems consuming Rawhide (or
> any other rolling stream). I created a Fedora Change[1] which got accepted
> already. We'll deliver support for module Obsoletes in DNF as soon as
> possible and we hope it's going to be used in Fedora 34 (or 35 at latest).
>
[...]
> [1]
> https://fedoraproject.org/w/index.php?title=Changes/Module_Obsoletes_and_EOL
Do you read a discussion for that page? Or where can I comment on the format
of the EOL data?
-- Petr
3 years, 7 months
Re: EOL and Obsoletes in Modularity
by Petr Šabata
On Tue, Nov 3, 2020 at 1:16 PM Petr Pisar <ppisar(a)redhat.com> wrote:
> Another option would be adding the EOL data into modules dist-git
> repositories. To the same branches where modules are built from. But
> a different file. Pungi would enumarate all module builds directed to
> a compose, locate their dist-git sources by mapping name:stream to
> git://src.fedoraproject/org/modules/name.git#stream and download EOL data from
> there. That would enable module maintains to control EOLs simply by pushing an
> eol.yaml file into the branch of the module.
This is not a reliable method as the branch name can be anything if
stream name is defined in modulemd. Technically even the repository name
can be anything.
You could look at the xmd section and check out the relevant commit used
to build it. That would imply you couldn't change EOL for already
built artifacts,
however. Only new ones.
Also I don't remember if xmd gets stripped during compose. If so, pungi
would need to ask MBS or Koji about every build.
P
3 years, 7 months
Re: EOL and Obsoletes in Modularity
by Petr Pisar
On Tue, Nov 03, 2020 at 02:17:59PM +0100, Petr Šabata wrote:
> On Tue, Nov 3, 2020 at 1:16 PM Petr Pisar <ppisar(a)redhat.com> wrote:
> > Another option would be adding the EOL data into modules dist-git
> > repositories. To the same branches where modules are built from. But
> > a different file. Pungi would enumarate all module builds directed to
> > a compose, locate their dist-git sources by mapping name:stream to
> > git://src.fedoraproject/org/modules/name.git#stream and download EOL data from
> > there. That would enable module maintains to control EOLs simply by pushing an
> > eol.yaml file into the branch of the module.
>
> This is not a reliable method as the branch name can be anything if
> stream name is defined in modulemd. Technically even the repository name
> can be anything.
>
I know. But In my option it's a problem of the module maintainer. (Doctor, it
hurts when I stab a needle into my eye! Doctor: Then don't do it.)
And even we had such a module build, the EOL format can be abused the same
way. You can EOL/obsolete foreign module:stream. Technically it can be misued
the same way to EOL a module build with overriden module:stream. You only need
to find a victim module repository to put it into. At the end, we already have
a fedora-osbolete-packages package. We can have fedora-obsolete-modules module
for the purpose of EOLing misnamed module builds.
In my opinion it's only a matter of policy.
-- Petr
3 years, 7 months
Re: EOL and Obsoletes in Modularity
by Petr Pisar
On Tue, Nov 03, 2020 at 03:22:45PM +0100, Vít Ondruch wrote:
> Have anybody considered to use AppData for that information? Or at least
> similar approach?
>
I haven't. AppData looks very similar to our use case. Thanks for the pointer.
-- Petr
3 years, 7 months
Re: Fedora 34 Change proposal: Modular GNOME Keyring services
(Self-Contained Change)
by Daiki Ueno
Michael Catanzaro <mcatanzaro(a)gnome.org> writes:
> On Wed, Nov 4, 2020 at 1:12 pm, Ben Cotton <bcotton(a)redhat.com> wrote:
>> Despite its original goal to be the central cryptographic service on
>> desktop, the scope of GNOME Keyring has been gradually reduced over
>> years. Notable examples are
>> [https://bugzilla.gnome.org/show_bug.cgi?id=750514 gpg-agent removal]
>> in 2015, [https://bugzilla.gnome.org/show_bug.cgi?id=791401 PKCS #11
>> module deprecation]
>
> Any plans to finish the PKCS#11 module deprecation work? Currently the
> module cannot be removed as it implements public gcr API needed by
> GNOME applications like geary.
It's a bit off-topic to this Change proposal, but let me briefly answer:
the original plan was to make the gcr API to use p11-kit-trust.so
instead of gnome-keyring.so to store the trust assertion information.
Later we realized that this approach requires significant effort,
including the enablement of p11-kit-trust's per-user trust store by
default, which is currently disabled at compile time.
On the other hand, the use-case is quite limited (the only affected
application I know of is geary). I suspect a more practical plan might
be to let gcr maintain trust assertions in a local file by its own. I
haven't had time to investigate this possibility further, but if anyone
is willing to work on it, that would be certainly appreciated.
Regards,
--
Daiki Ueno
3 years, 7 months
