https://bugzilla.redhat.com/show_bug.cgi?id=1154154 is a request to provide a generic-release-workstation (sub)package in order to allow for convenient remixing of a debranded Fedora Workstation. It seemed odd that firewalld-config-workstation would require system-release-workstation and if this were to be done we'd need to be sure not to break Fedora composes. I was hoping to hear some comments from the workstation group in the ticket.

On Fri, Oct 17, 2014 at 16:18:21 -0400, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote: > > > >On Fri, 2014-10-17 at 14:46 -0500, Bruno Wolff III wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=1154154 is a request to provide >> a generic-release-workstation (sub)package in order to allow for >> convenient remixing of a debranded Fedora Workstation. >> >> It seemed odd that firewalld-config-workstation would require >> system-release-workstation and if this were to be done we'd need to be >> sure not to break Fedora composes. I was hoping to hear some comments >> from the workstation group in the ticket. > >firewalld-config-workstation requires system-release-workstation >specifically to enable the creation of generic-release-workstation >packages. (Both generic-release-workstation and >fedora-release-workstation would Provides: system-release-workstation) I was thinking that that was probably the case with using system in the name. Though I was also wondering why the dependency was there at all. (Though that is moot if it is OK to add a generic version.)

On Fri, 2014-10-17 at 16:18 -0400, Stephen Gallagher wrote: > > > On Fri, 2014-10-17 at 14:46 -0500, Bruno Wolff III wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=1154154 is a request to provide > > a generic-release-workstation (sub)package in order to allow for > > convenient remixing of a debranded Fedora Workstation. > > > > It seemed odd that firewalld-config-workstation would require > > system-release-workstation and if this were to be done we'd need to be > > sure not to break Fedora composes. I was hoping to hear some comments > > from the workstation group in the ticket. > > firewalld-config-workstation requires system-release-workstation > specifically to enable the creation of generic-release-workstation > packages. (Both generic-release-workstation and > fedora-release-workstation would Provides: system-release-workstation) Not sure I understand this. Why does firewalld-config-workstation need to require any release package ? That seems backwards to me.

On Mon, 2014-10-20 at 09:36 -0400, Stephen Gallagher wrote: > > Not sure I understand this. Why does firewalld-config-workstation need > > to require any release package ? That seems backwards to me. > > > > It's a relic of the way the dependency-resolution has to work. When > installing the 'firewalld' package (or any other package that > potentially needs to have a different configuration on one product than > another), we need to have a way for yum and dnf to pick the correct > configuration package. > > We can't do the reverse -- have [fedora|system]-release-workstation > depend on firewalld-config-workstation -- in the general case because it > would force the inclusion of the application into the unremovable set. > In the firewalld case, this would probably be acceptable, but in the > case of something like Apache (which has been suggested would probably > benefit from different defaults on Server and Workstation), it really > wouldn't be. > > So the specific need for the dependency there is to work around > depsolving limitations. Please trust me that when I put that proposal > together, I talked to the RPM, yum, dnf and anaconda folks as well as > getting the proposal approved by the FPC. It's the only feasible way to > do this at the moment (upcoming RPM enhancements with advanced > dependencies may make this better, but those aren't going to show up any > sooner than F23). I trust you. But I still don't think this is right. The way it should work is that firewalld-config-workstation provides firewalld-config firewalld requires firewalld-config fedora-release-workstation requires firewalld-config-workstation and firewalld > it would force the inclusion of the application into the unremovable > set Only if you make firewalld-config-workstation require firewalld - I don't think you should.

On Mon, Oct 20, 2014 at 09:54:59AM -0400, Stephen Gallagher wrote: > 1) You now have to release an update for fedora-release-workstation > every time a new package gets a per-product configuration (to add the > new Requires) I think that's okay. That kind of change should generally happen as part of the release development cycle, not arbitrarily.

> 2) Every deployment of Workstation now carries configuration for > packages that may never be installed (and configuration isn't > necessarily small, though most of the time it will be). Do you have an example that _isn't_ small?

> 3) From a user's perspective, if they see configuration for a service or > application in their package list, they may assume that package is > installed and running, leading to confusion. That is more worrying, yes.

On 10/20/2014 04:08 PM, Matthew Miller wrote: >> 3) From a user's perspective, if they see configuration for a service or >> application in their package list, they may assume that package is >> installed and running, leading to confusion. > > That is more worrying, yes. If showing a separate package in the installed package list is a problem, then the configuration files could be shipped directly in the fedora-release-* packages too. Which also incidentally makes the whole thing much easier to handle because that way we'd have less conflicting packages in the repository. I'm sure there are downsides to this though, like configuration possibly getting out of sync with the actual programs if nobody takes care of updating the fedora-release-* packages.

On Mon, 2014-10-20 at 09:54 -0400, Stephen Gallagher wrote: > > > On Mon, 2014-10-20 at 09:44 -0400, Matthias Clasen wrote: > > On Mon, 2014-10-20 at 09:36 -0400, Stephen Gallagher wrote: > > > > > > Not sure I understand this. Why does firewalld-config-workstation need > > > > to require any release package ? That seems backwards to me. > > > > > > > > > > It's a relic of the way the dependency-resolution has to work. When > > > installing the 'firewalld' package (or any other package that > > > potentially needs to have a different configuration on one product than > > > another), we need to have a way for yum and dnf to pick the correct > > > configuration package. > > > > > > We can't do the reverse -- have [fedora|system]-release-workstation > > > depend on firewalld-config-workstation -- in the general case because it > > > would force the inclusion of the application into the unremovable set. > > > In the firewalld case, this would probably be acceptable, but in the > > > case of something like Apache (which has been suggested would probably > > > benefit from different defaults on Server and Workstation), it really > > > wouldn't be. > > > > > > So the specific need for the dependency there is to work around > > > depsolving limitations. Please trust me that when I put that proposal > > > together, I talked to the RPM, yum, dnf and anaconda folks as well as > > > getting the proposal approved by the FPC. It's the only feasible way to > > > do this at the moment (upcoming RPM enhancements with advanced > > > dependencies may make this better, but those aren't going to show up any > > > sooner than F23). > > > > I trust you. But I still don't think this is right. The way it should > > work is that > > > > firewalld-config-workstation provides firewalld-config > > firewalld requires firewalld-config > > fedora-release-workstation requires firewalld-config-workstation and > > firewalld > > > > > it would force the inclusion of the application into the unremovable > > > set > > > > Only if you make firewalld-config-workstation require firewalld - I > > don't think you should. > > I see your point (and I agree I'd rather see something like it), but it > still has the following problems: > > 1) You now have to release an update for fedora-release-workstation > every time a new package gets a per-product configuration (to add the > new Requires) That doesn't happen during the life-time of a released product. And we have to update fedora-release-workstation for the next release anyway. > 2) Every deployment of Workstation now carries configuration for > packages that may never be installed (and configuration isn't > necessarily small, though most of the time it will be). > > 3) From a user's perspective, if they see configuration for a service or > application in their package list, they may assume that package is > installed and running, leading to confusion. You're doing what every good engineer would do, and try to architect the most general solution that handles arbitrary cases. I'm just looking at the situation for the product at hand, the F21 workstation. firewalld _is_ installed as part of the F21 workstation, right ? > What I'm looking forward to in the F23 timeframe is that RPM is expected > to grow the ability to specify dependency conditionals. For example if I > install the Apache package, it would have: > > CondRequires: apache-config-workstation if system-release-workstation > CondRequires: apache-config-server if system-release-server > > This will be much cleaner. (The syntax above is probably not exactly > right, but it's the general idea) Something to look forward to, then. Although I have a hard time coming up with a good reason for having apache-config-workstation - the only cases where I can see product-specific configurations make sense is included system services that need to behave differently in one product vs the other. A dedicated server app like apache should just do what it does, not morph into doing subtly different things depending on where it was installed.