#671 Packages packaging yum repo files?
Closed None Opened 12 years ago by notting.

= Proposal topic =

Some packages in Fedora package yum repo files. We should discuss under what circumstances this is OK.

Example #1: xen package:

{{{
$ cat dom0-kernel.repo
[dom0-kernel]
name=Experimental pv_ops/dom0 kernels for Fedora - $basearch
baseurl=http://repos.fedorapeople.org/repos/myoung/dom0-kernel/fedora-12/$basearch/
enabled=0
gpgcheck=0

[dom0-kernel-source]
name=Experimental pv_ops/dom0 kernels for Fedora - Source
baseurl=http://repos.fedorapeople.org/repos/myoung/dom0-kernel/fedora-12/SRPMS/
enabled=0
gpgcheck=0
}}}

Example #2: retrace-server package
{{{
$ cat retrace-server.repo
[retrace-fedora-15-i386]
name=Fedora 15 - i386
failovermethod=priority
baseurl=file:///var/cache/retrace-server/fedora-15-i386/
enabled=0

[retrace-fedora-15-x86_64]
name=Fedora 15 - x86_64
failovermethod=priority
baseurl=file:///var/cache/retrace-server/fedora-15-x86_64/
enabled=0

[retrace-fedora-16-i386]
name=Fedora 16 - i386
failovermethod=priority
baseurl=file:///var/cache/retrace-server/fedora-16-i386/
enabled=0

[retrace-fedora-16-x86_64]
name=Fedora 16 - x86_64
failovermethod=priority
baseurl=file:///var/cache/retrace-server/fedora-16-x86_64/
enabled=0

}}}

Referred to FESCo by FPC chair on asking him the policy.


I think it should be fine if the repositories in these repo files are disabled by default and the user has to manually enable them.

This was discussed before on both the packaging list and the, then, extras list by members of FPC and FESCo. We voted on list to deny this. This was long enough ago that I don't recall if I discussed this as a member of FESCo or a member of the FPC (and perhaps in those wilder, woolier days, the distinction was not as important).

https://www.redhat.com/archives/fedora-packaging/2006-October/msg00132.html
https://www.redhat.com/archives/fedora-extras-list/2006-December/msg00344.html

Browsing the threads again, the only person I see asking for the repo files to be live (in /etc/yum.repos.d) is the package maintainer himself. Everyone else from FESCo, FPC, and other package maintainers are weighing in negatively. It looks like this never went to either FESCo or FPC to be written into policy.

I'd propose that this goes to the FPC as "Configuration for package managers in Fedora MUST only reference the official Fedora repositories in their default enabled and disabled state (see the yum repo configuration in the fedora-release package for the canonical list). If the package wishes to include additional repository configuration, those may be included in the package's documentation. Copying the example repository configuration files (or the information within them) from the documentation directory to the package manager's configuration location must be an explicit step that the system administrator chooses to make to enable these repositories."

Stated this way, it seems to be an FPC issue as it's how to package this sort of information.

Note -- For the two repositories listed as examples above, I think that the first should definitely be packaged as documentation. The second I'm not sure of the reason it exists. It may be that that one is a candidate to be merged into the fedora-release package instead of being packaged as documentation. Determining what repositories belong in fedora-release would be a FESCo issue.

Commenting here since I won't be in the meeting - the first is right out, and should not be allowed. The second appears to be an implementation detail of the daemon - it looks like it does repository syncs? Would need more information on what it's trying to do there.

I suppose one necessary (but not necessarily sufficient) criterion for allowing this must be that the repository doesn't contain any Forbidden Items. Otherwise we're going to see rpmfusion-*-release submitted for review tomorrow. ;-)

Fesco agreed that having these files distributed in /etc/yum.repos.d was inappropriate and that FPC should come up with appropriate policy to explain how to distribute config fragments.

Login to comment on this ticket.

Metadata