On Sat, Sep 24, 2016 at 3:44 PM, Ben Rosser <rosser.bjr@xxxxxxxxx> wrote: > 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. 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 would > automatically become slightly more "legitimate" across the entire > distribution than repositories that were not accepted. Then if two Nope. > 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). 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 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. 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 fix. > 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. 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 offering it. > 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. 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 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. 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 WGs to > 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. josh _______________________________________________ council-discuss mailing list -- council-discuss@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to council-discuss-leave@xxxxxxxxxxxxxxxxxxxxxxx
