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, 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)
On Fri, Oct 17, 2014 at 16:18:21 -0400, Stephen Gallagher sgallagh@redhat.com 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 15:16 -0500, Bruno Wolff III wrote:
On Fri, Oct 17, 2014 at 16:18:21 -0400, Stephen Gallagher sgallagh@redhat.com 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.)
For details on that, see https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration
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 08:54 -0400, Matthias Clasen wrote:
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.
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).
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, 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)
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.
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)
On Mon, Oct 20, 2014 at 09:54:59AM -0400, Stephen Gallagher wrote:
- 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.
- 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?
- 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 Mon, 2014-10-20 at 10:08 -0400, Matthew Miller wrote:
On Mon, Oct 20, 2014 at 09:54:59AM -0400, Stephen Gallagher wrote:
- 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.
Sure, but now we're talking policy solutions instead of technical ones.
- 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?
I can't come up with a real-world example of this, just hypotheticals (such as having configuration in the form of a multi-megabyte compiled data file).
- 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:
- 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 16:44 +0200, Kalev Lember wrote:
On 10/20/2014 04:08 PM, Matthew Miller wrote:
- 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.
Polluting the fedora-release packages with internal details of other packages seems like a terrible idea to me, honestly. Configuration should remain with the package (and packager) that understands it.
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:
- 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.
- 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).
- 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.
On Mon, 2014-10-20 at 10:15 -0400, Matthias Clasen wrote:
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:
- 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.
- 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).
- 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.
This is getting off-topic, but it has been proposed that on Server, it makes sense for the default Apache configuration to be for deployments, but for Workstation it might make more sense for it to be designed to limit it to the local system for development purposes (presumably with a simple toggle to switch to "production" mode).
desktop@lists.fedoraproject.org
-
Bruno Wolff III -
Kalev Lember -
Matthew Miller -
Matthias Clasen -
Stephen Gallagher