On Sat, Sep 24, 2016 at 12:51 PM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> 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.
_______________________________________________ council-discuss mailing list -- council-discuss@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to council-discuss-leave@xxxxxxxxxxxxxxxxxxxxxxx
