On Sat, Sep 24, 2016 at 12:51 PM, Josh Boyer <jwboyer(a)fedoraproject.org>
wrote:
> 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.
In other words, any repository that was accepted for any edition would
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, someone
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 [1]. The package I
made puts all user-generated game data (configuration, saves, mods, etc.)
in ~/.dwarffortress/. [2] (I know the nonfree part of the proposal is still
up in the air, but let's assume it is approved too).
Let's suppose I submit this repository to consideration for inclusion in
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 repository exists.
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 other edition.
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
somewhat.)
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.
2. Users who don't run either edition now need to choose between two
difficult-to-distinguish, both seemingly just as "officially unofficial"
places to install Dwarf Fortress from.
3. The upstream Dwarf Fortress community now needs to worry about which
version of the package Fedora users have installed when documenting things,
and also which edition users are running when telling them how to install
the software.
Now, possibly when the second person proposed the repository shipping the
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.
Does that make sense? As I read it, the policy doesn't require WGs to
collaborate and try and stop something like the above scenario from
happening. Perhaps I'm interpreting it wrong though.
Ben Rosser
[1]
https://www.acm.jhu.edu/~bjr/pages/dwarf-fortress-for-fedora.html (this
is an actual repository I maintain and not something i invented just for
the sake of argument here).
[2] This is a problem for DF specifically because DF cannot be installed
system-wide and does not have a default installation directory, so
downstream packages must install the files system-wide and then symlink
them into a user's home directory when DF is first ran by that user.
~/.dwarffortress/ was the convention chosen by the Arch Linux packagers,
but Arch is the only major distribution which packages DF so this is not
really a standard at the moment.