On Sat, Sep 24, 2016 at 3:44 PM, Ben Rosser <rosser.bjr(a)gmail.com> wrote:
On Sat, Sep 24, 2016 at 12:51 PM, Josh Boyer
> > Sure, and I think that is admirable. But I guess I'm approaching this
> > from the view of someone who has not productized (editionized?) most of his
> > Fedora installations, because they were installed before Fedora 2 and I
> > chose not to do so when upgrading. If this is a per-edition thing, how would
> > I enable officially sanctioned third-party software repositories? Or what if
> > I'm running a desktop spin that chooses not to ship any of, say,
> > Workstation's 3rd party repositories for whatever reason? Presumably, there
> > would be some way for me pick and choose them despite not having an
> > editionized installation.
> The same way you do right now...
Okay, I think this is perhaps the root of my confusion / issue here.
I was assuming there would be some centralized Fedora listing of these third
party repositories for *all* Fedora, and individual editions would
cherry-pick from that list which ones to install in a disabled state (that
could then be activated by dnf, GNOME Software, etc). But I guess I was also
assuming there would be some kind of tooling that would allow *any* fedora
user to install and enable *any* third party from this list as easily as,
say, "dnf copr enable foo/bar" currently is.
No. It's entirely dependent on the individual WG to curate their own list.
In other words, any repository that was accepted for any edition
automatically become slightly more "legitimate" across the entire
distribution than repositories that were not accepted. Then if two
repositories for the same software were accepted by different WGs,
not using either edition would have two "legitimate" places to get that
software from that might be incompatible with each other.
> I'm still having trouble understanding the theoretical problem. Could you
> perhaps give a concrete example?
So with the above assumption, here's a concrete example (albeit somewhat of
a contrived one, because it is a games package and thus primarily only
suited to editions/spins with desktop environments):
I maintain a third-party repository with RPMs for a nonfree game, Dwarf
Fortress, and some associated FOSS utilities that cannot be packaged in
Fedora because they depend directly on said nonfree game . The package I
made puts all user-generated game data (configuration, saves, mods, etc.) in
~/.dwarffortress/.  (I know the nonfree part of the proposal is still up
in the air, but let's assume it is approved too).
Nonfree was included in the third party repository approval. That
needs to be vetted before it can be included in an Edition though. It
isn't a free-for-all.
Let's suppose I submit this repository to consideration for
Fedora Workstation, so that if someone searches for "Dwarf Fortress" and
consents to be shown nonfree, third-party software, they can optionally
enable my repository and install my RPMs. However, it does not meet the
guidelines for inclusion on other editions, and I'm not interested in fixing
that for whatever reason. But that's okay, because if someone _really_ wants
to run this game on another edition, they can run "dnf thirdparty enable
tc01/dwarffortress", or something like that, provided they know the
Now let's suppose someone _else_ wants to package the same game, but for a
different edition. However, their package chooses to put game data in, say,
~/.local/share/dwarffortress/, and ships with a slightly different set of
associated utilities. (Or perhaps different versions of said utilities).
Their repository is approved though, because it meets the guidelines for the
At this point, if we only concern ourselves with the edition/spin level
view, everything seems fine-- users of both editions can search for "Dwarf
Fortress" and install it, provided they consent to be shown nonfree, third
party repositories. However, if we move beyond the edition/spin level to
look at either the distribution as a whole, or the upstream community as a
whole, there are now several problems. (Granted, these are not *major*
problems, and all these problems would exist already if multiple people
packaged the software separately regardless as to whether or not Fedora
sanctions them or not, but if Fedora only sanctioned *one* such repository
regardless of which editions wanted to ship it, they could be mitigated
1. If I run Workstation and someone else runs the other edition, or if I
have two machines and one runs each edition, there will now be confusion if
I want to e.g. copy game data back and forth, or assume that a certain
version of a certain utility is available from both sources when it is only
provided by one.
Sounds like something that could be solved with a symlink. I
understand the concern, but I do not believe we need distro-wide
policing of repositories to avoid something that is fairly trivial to
2. Users who don't run either edition now need to choose between
difficult-to-distinguish, both seemingly just as "officially unofficial"
places to install Dwarf Fortress from.
This problem exists today. Having Editions offer software from third
party repositories doesn't help it. In fact, it cannot as the very
definition of "third party" means someone other than Fedora is
3. The upstream Dwarf Fortress community now needs to worry about
version of the package Fedora users have installed when documenting things,
and also which edition users are running when telling them how to install
Actually, this is where the ideal solution comes from. If the
upstream community themselves were to create the third party
repository, chances are very good that all Editions would use that.
This is actually one of the primary motivators for having the
repository policy approved in the first place. An enterprising Fedora
contributor could even work with the upstream community to help them
create such a repo.
Now, possibly when the second person proposed the repository shipping
same software for review, the reviewer _should_ have said "hey, Workstation
already signed off on a third-party repository for this software, why don't
you try to collaborate with them", and only approved the second repository
should there have been some fundamental reason that reconciling the two
repositories was impossible (differing package formats for each edition,
etc). Maybe that is what will happen, or perhaps this is a problem fixable
by some sort of repository review tool that doesn't need policy. But this is
the main source of my concern: that we'll end up with three different lists
of curated third party repositories that conflict with each other, and that
these conflicts will just make life more difficult for users who are stuck
either with multiple editions, or not using a specific edition at all.
Those not using a specific edition at all are on their own, so lumping
them into this problem set isn't really valid.
Does that make sense? As I read it, the policy doesn't require
collaborate and try and stop something like the above scenario from
happening. Perhaps I'm interpreting it wrong though.
It doesn't require them to, no. However, I do think people reporting
similar issues as they arise can help avoid this.