F42 Change Proposal: GNOME Shell extension Dependency Generator (system-wide)

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

 



Wiki - https://fedoraproject.org/wiki/Changes/GnomeShellExtensionDependencyGenerator
Discussion thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-gnome-shell-extension-dependency-generator-system-wide/140618

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Implement a dependency generator for GNOME Shell extensions that would
make the binary RPM depend on the correct versions of GNOME Shell

== Owner ==
* Name: [[User:salimma|Michel Lind]], [[User:ngompa|Neal Gompa]]
* Email: michel@xxxxxxxxxxxxxxx, ngompa13@xxxxxxxxx

== Detailed Description ==
GNOME Shell extensions ship with a `metadata.json` that lists the
supported versions of GNOME Shell. This data is currently unused when
packaging an extension, unless the package maintainer explicitly
transfer this information to the spec -- and then keeps it up to date.

With this Change Proposal implemented, the binary RPM would
automatically declare its dependency on the right versions of GNOME
Shell, ensuring that we will discover after mass rebuild if some
extensions need to be updated because they will FTI.

== Feedback ==

== Benefit to Fedora ==
This will result in an improved user experience for our users, because
extensions that install are now more likely to work.

It will also help extension packagers, as they get early signal that
an extension needs to be updated, by getting a FTI bug not long after
the mass rebuild is complete.

== Scope ==
* Proposal owners:
** Implement a dependency generator and package it as
`gnome-shell-extension-rpm-macros`
** make `gnome-shell` `Provides: gnome-shell(api) == MAJOR_VER` to
make the implementation of the generator easier
** Get this package pulled in by `redhat-rpm-config`
** Optionally get this into `epel-rpm-macros` for EPEL 10
** Provide a COPR for other developers to test

* Other developers:
** Test your package by explicitly adding the new dependency generator
package as a `BuildRequires` and dropping the `Requires` on
`gnome-shell`
** If that works, once the new package is in Fedora and pulled in by
`redhat-rpm-config`, you may (but do not have to) drop the `Requires`
on `gnome-shell` as it will be redundant


* Release engineering: [https://pagure.io/releng/issues #Releng issue number]

* Policies and guidelines:
[https://pagure.io/packaging-committee/pull-request/1425 FPC #1425]
This should only land after implementation is done

* Trademark approval: N/A (not needed for this Change)

* Alignment with the Fedora Strategy:

== Upgrade/compatibility impact ==

N/A. This change would be transparent to packagers and end-users - it
will allow packagers to clean up their spec by removing the explicit
`Requires` on `gnome-shell` but that is optional


== Early Testing (Optional) ==

== How To Test ==


== User Experience ==


== Dependencies ==

This requires changes to `gnome-shell` and optionally
`redhat-rpm-config`. The former significantly eases implementation, as
it allows a 1:1 mapping between the version listed in `metadata.json`
and what we express in the binary RPM. The latter is required to make
this transparent to other packagers; if that change does not go
through this becomes a self-contained change and extension maintainers
can opt in by BR-ing the package


== Contingency Plan ==

* Contingency mechanism: (What to do?  Who will do it?)
If the dependency generator turns out to be very buggy, we can stop
pulling it in `redhat-rpm-config`

* Contingency deadline:
Beta freeze

* Blocks release? No

== Documentation ==

N/A

== Release Notes ==

-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney

-- 
_______________________________________________
devel-announce mailing list -- devel-announce@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-announce-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- 
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux