----- Original Message ----- > On Mar 17, 2015 5:18 AM, "Jan Zelený" <jzeleny@xxxxxxxxxx> wrote: > > > > On 16. 3. 2015 at 15:52:10, Jaroslav Reznik wrote: > > > = Proposed Self Contained Change: Disabled Repositories Support = > > > https://fedoraproject.org/wiki/Changes/DisabledRepoSupport > > > > > > Change owner(s): Richard Hughes <rhughes at redhat dot com> > > > > > > The Software tool and PackageKit now support disabled repositories to > help > > > users locate software in additional repositories which are not meant to > be > > > enabled by default. > > > > > > * This Change is announced after the Change Submission Deadline as an > > > exception to the process. May not be approved for proposed Fedora > release. * > > > > > > == Detailed Description == > > > This feature aims to reduce the technical hurdles for users and > developers > > > to locate software packaged for a distribution, but which needs to be > > > clearly identified as not officially included (or possibly sanctioned) > by > > > that distribution. > > > > > > When Software (via PackageKit) queries a repo definition that contains > the > > > line enabled_metadata=1, even if the repo is disabled, it will download > > > repodata. This feature allows a user to locate software in response to a > > > search. If the user wants to install the software, she receives a dialog > > > with information that the repo must be enabled to satisfy the request, > and > > > if relevant, information about the nature of the software (for > instance, if > > > it is non- libre). > > > > > > N.B. This feature does not currently operate in Fedora, since no such > repo > > > definitions are currently shipped. However, the feature could be used by > > > remixers, and in the future in Fedora in the event of a policy change. > > > > > > == Scope == > > > * Proposal owners: Include enhancements in gnome-software/PackageKit > (done) > > > * Other developers: N/A (not a System Wide Change) > > > * Release engineering: N/A (not a System Wide Change) > > > ** Note: For this feature to be used in Fedora requires an additional *- > > > release-extra package to ship disabled repo definition > > > * Policies and guidelines: N/A (not a System Wide Change) > > > ** Note: For this feature to be used in Fedora requires clearer approval > > > from FESCo and the Council > > > > I wonder, are there any implications for dnf in terms of being consistent > with > > the new behavior of Gnome Software? I realize that people using dnf have > more > > options than people using Gnome Software (--enablerepo for instance) but > this > > sounds like the beginning of the end of disabled repositories. > > > > Personally, I don't like the semantics of these semi-disabled repos. It > beats > > the purpose of disabling the repos in the first place, doesn't it? I mean > I > > don't get why user would specify enabled_metadata=1 when he can achieve > almost > > the same result with disabled=0 (the only difference I can see is one > > additional popup dialog). Or is there something I'm missing? > > > > Thanks > > Jan > > -- > > As I understand it, the intent is to provide the user with the experience > of third party software being included in Fedora, while still complying > with the third party repository policy and communicating to the user that > it comes from somewhere else. > > As I understand it, the council stance is that each repo must be a > self-contained piece of software, and each individual repo must have > explicit council approval to be included, with a mandate for furthering > Fedora's mission and an expectation of permissive licensing. In that > context, I guess I'm ok with the compromise. > > jreznik, what about cycling these approvals through the Change process, but > instead of going to Fesco, the tickets go to the council? That would allow > a sufficient amount of community scrutiny and signal, IMO. The Change > template would only need to be modified slightly, probably not more than > current interpretations do. That's one of future goals to use Change process not only for Changes that has to go through FESCo but WGs, for this case Council. Actually, the new process was initially designed this way :). It will require some change in template but it's doable and it can help coordination with other parts of Fedora as we do for example for Release Notes. So, count me in :). Jaroslav > > --Pete > -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
