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
> > 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
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
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.