Bug 187250

Created attachment 126994 [details]
Patch to split off config files from main package

By being in the same source package, one would have to be bumped in order to
bump the other, and you'll end up updating both packages anyway, so how does
this help?

I'd welcome a separate fedora-config-package, too, but wasn't bold enough to
recommend doing so.

But even as it stands (common source package) the split-off packages can be
replaced to adhear to local policies, e.g. local mirrors.

So separate source packages would be perfect, while common source and
sub-packaging is second best, but still a lot better than all-in-one. :)

Would you like me to come up with a split source-package scenario (specfiles)?

I'm working with the docs team so that release-notes is a stand alone package,
and fedora-release has the rest of the bits.  This is targetted to happen prior
to Test 2.

I suggest to name the package containing the depsolver sources different that
fedora-release. The reasons are that

o fedora-release inmplies that release notes should be found in there
o configuration packages from other depsolvers (apt and yum) in fedora are named
  fedora-package-config-apt or fedora-package-config-smart, e.g. they are
  suffixing the not-yet-existing main package with -<depsolver>, in case the
  main package with the yum config keeps the fedora-release name, these would be
  named fedora-release-apt and fedora-release-smart?
o Some repos have derived (wrong IMO) names for the respective depsolver config
  packages like {freshrpms,rpmforge,livna}-release. This naming implies that
  there is an actual release of these 3rd party repos, which doesn't exist. Not
  even Fedora Extras has a release, all but Fedora Core are "rolling releases"

Please keep fedora-release for the release notes and name the depsolver config
package something different. Maybe not fedora-package-config, but something that
would also allow for apt/smart to suffix themselves onto it for their own
packages. Maybe one of yum-config, repo-config, repomd-config etc.

Thanks!

Forgot to add that I would promote the use of the new depsolver config name to
all affected parties (Dag/Dries/livna/extras/freshrpms etc. and ATrpms) to take
it into account before FC6.

Currently the release notes have been moved to another package, thanks Jesse.

But there is still an issue with bundeling /etc/*release, /etc/issue*, /etc/pki
and the eula with the actual repo configuration. E.g. in a local mirror
environment I want to replace the latter but not any of the release-invariant
parts like say /etc/fedora-release or the eula.

My initial report wasn't using the correct wording, I was subsumming anything
but the repo config (release notes and the release invariant parts) as
"release-notes", sorry for that. :/

The key idea remains: Allowing to locally replace the repo config on a package
level w/o removing any of the non-repo-config parts like release-notes, eula,
/etc/*release, /etc/issue* and pki.

Again, sorry for suggesting the split on the wrong content border due to poor
wording :(

Any chance we could get this fixed? Thanks!

It has been discussed and decided that no futher splitting would be acceptable.
 Getting your own configs in place is pretty easy using some %post fun and whatnot.

Where was this discussed and decided, was it on an open list or internally? Why
isn't it acceptable, e.g. what is the downside? Please don't just reject this
topic with so little detail.

Manipulating another package's file content in %post* is error-prone and clumsy
at the very least. It would introduce more problems than it would solve.

If this stays a WONTFIX then users and admins are left with two options:

a) change the config manually - works for a couple of administrated stations
b) perform the split themselves and craft the alternative repo packages to
   fulfill their needs. The splitted packages are equal to the original one,
   only that the config part can be replaced, e.g. just what this report was
   about.

Would you please reconsider splitting the package at vendor level? Workaround a)
and b) may sound acceptable, but some people consider workarounds like b), e.g.
splitting fedora-release into two parts as "Core package replacement", which
semantically it is not, but technically it is.

It would make both large site admins and 3rd party repo maintainers as well as
their users very happy. ;)

Anyway if not, at least there is an entry here to point people to when the issue
comes up. But some reasoning on why this is rejected would be nice.

It was discussed with Bill Nottingham and Jeremy Katz, technical leads of Core.
 What it boils down to is we don't really see what this will accomplish.  Even
with a split you're STILL going to have to replace a core package or modify
contents in place.  Further splitting out of the fedora-release stuff doesn't
fix that.  In a large site, the repos can be replaced/adjusted in the kickstart
%post section, or they can have their own fedora-release package in the repo,
complete with their own site gpg key and site addon-repo added.  For 3rd party
repo maintainers, why would you want to replace the existing core/extras repo? 
Wouldn't you just be ADDING your repo to the mix?

(In reply to comment #10)
> Even with a split you're STILL going to have to replace a core package

Yes, but it makes a difference if the to be replaced package only replaces
pointers to the repos, e.g. the yum/up2date config, or other very prominent
parts of it, e.g. /etc/*-release, /etc/issue*, the EULA and the pki infrastructure.

> For 3rd party repo maintainers, why would you want to replace the existing
> core/extras repo? Wouldn't you just be ADDING your repo to the mix?

That's a valid question, the answer is that ATrpms users for example have often
reported that they have very good access to ATrpms' packages, but a dead-slow
connection to the automatic selected mirror. They also have troubles configuring
a new mirror. This all spoils the Fedora experience especially to novices. As a
service ATrpms offers high speed mirrors (3 x 2GB connected mirrors on a 10GB
backbone) of vendor as well as other 3rd party repos.

In a scenario where the yum/up2date config lives alone in a package these users
can *optionally* (when they encounter the troubles) install a replacement
package pointing to these mirrors. In a bundled scenario like it is now it's
either a) or b) above.

I mentioned ATrpms too often, don't consider this an ATrpms thing, I was just
giving an example. See also
http://www.redhat.com/archives/fedora-devel-list/2006-March/msg01334.html for a
non-ATrpms request.

Anyway the split won't hurt the normal workflow and it will give added value to
local mirrorers and 3rd party repos.

(In reply to comment #11)
> (In reply to comment #10)
> > Even with a split you're STILL going to have to replace a core package
> 
> Yes, but it makes a difference if the to be replaced package only replaces
> pointers to the repos, e.g. the yum/up2date config, or other very prominent
> parts of it, e.g. /etc/*-release, /etc/issue*, the EULA and the pki
infrastructure.

Thats really just symantics.  Also, without hand modifying the config files, how
do you prevent the next fedora-yumconfig package issued by Fedora from
overwriting your replacement package files?  Are you going to so some trickery
with epochs?  Asking users to excludepkg from configs, etc..?

> > For 3rd party repo maintainers, why would you want to replace the existing
> > core/extras repo? Wouldn't you just be ADDING your repo to the mix?
> 
> That's a valid question, the answer is that ATrpms users for example have often
> reported that they have very good access to ATrpms' packages, but a dead-slow
> connection to the automatic selected mirror. They also have troubles configuring
> a new mirror. This all spoils the Fedora experience especially to novices. As a
> service ATrpms offers high speed mirrors (3 x 2GB connected mirrors on a 10GB
> backbone) of vendor as well as other 3rd party repos.
> 
> In a scenario where the yum/up2date config lives alone in a package these users
> can *optionally* (when they encounter the troubles) install a replacement
> package pointing to these mirrors. In a bundled scenario like it is now it's
> either a) or b) above.

Why aren't your mirrors listed in the official mirror list, which now uses geoip
to provide a local mirror to the user rather than a random mirror?  The solution
is to fix the mirroring system, not replace it wholesale.

> I mentioned ATrpms too often, don't consider this an ATrpms thing, I was just
> giving an example. See also
> http://www.redhat.com/archives/fedora-devel-list/2006-March/msg01334.html for a
> non-ATrpms request.

That request is junk.  If you've got a local mirror, and you've modified your
yum configs, new fedora-release packages will write out .rpmnew files, not
overwrite the existing files.  

> Anyway the split won't hurt the normal workflow and it will give added value to
> local mirrorers and 3rd party repos.
> 

The split complicates things more than it really should, with no real gain that
I can see.

(In reply to comment #12)
> > Yes, but it makes a difference if the to be replaced package only replaces
> > pointers to the repos, e.g. the yum/up2date config, or other very prominent
> > parts of it, e.g. /etc/*-release, /etc/issue*, the EULA and the pki
> > infrastructure.
> 
> Thats really just symantics.

Semantics are important.

> Also, without hand modifying the config files, how
> do you prevent the next fedora-yumconfig package issued by Fedora from
> overwriting your replacement package files?  Are you going to so some trickery
> with epochs?  Asking users to excludepkg from configs, etc..?

No, why should one do such nasty things? Just check out how smart and apt work.
They already have this idiom in place.

> Why aren't your mirrors listed in the official mirror list,

That's one of the main PITA, they *ARE* official mirrors. But even *the servers
themselves* don't get redirected to themselves ...

> The solution is to fix the mirroring system, not replace it wholesale.

That's orthogonal, and the user complaints are there and need to be taken care
of now. If in the future the mirror system works better some arguments on favour
of the split would drop, but it's not happening with FC6.

> > Anyway the split won't hurt the normal workflow and it will give added value
> > to local mirrorers and 3rd party repos.
> 
> The split complicates things more than it really should, with no real gain
> that I can see.

If you are not doing large site maintenance with local mirroring or are a 3rd
party repo maintainer/user like outlined above you don't have gain, but you
don't have drawbacks, too. We'd like to get more people happy, the demand is
there and it costs nothing.

The package was already split for lesser reasons (IMHO) to separate off the
release docs, why not split off the repo config, too?

(In reply to comment #13)
> > Also, without hand modifying the config files, how
> > do you prevent the next fedora-yumconfig package issued by Fedora from
> > overwriting your replacement package files?  Are you going to so some trickery
> > with epochs?  Asking users to excludepkg from configs, etc..?
> 
> No, why should one do such nasty things? Just check out how smart and apt work.
> They already have this idiom in place.

The idiom to do what?  A newer package is available in a configured repo.  What
idiom is automatically in place that states "do not update this package, its
speshul"?
 
> > Why aren't your mirrors listed in the official mirror list,
> 
> That's one of the main PITA, they *ARE* official mirrors. But even *the servers
> themselves* don't get redirected to themselves ...
> 
> > The solution is to fix the mirroring system, not replace it wholesale.
> 
> That's orthogonal, and the user complaints are there and need to be taken care
> of now. If in the future the mirror system works better some arguments on favour
> of the split would drop, but it's not happening with FC6.

It _IS_ happening for FC6.  The development repo config files I shipped a short
time ago make use of Geiop for correct mirror assignment.

> > > Anyway the split won't hurt the normal workflow and it will give added value
> > > to local mirrorers and 3rd party repos.
> > 
> > The split complicates things more than it really should, with no real gain
> > that I can see.
> 
> If you are not doing large site maintenance with local mirroring or are a 3rd
> party repo maintainer/user like outlined above you don't have gain, but you
> don't have drawbacks, too. We'd like to get more people happy, the demand is
> there and it costs nothing.

The demand is you, and it costs overhead and complexity, and I _still_ don't see
how it gains the above mentioned userbase in any way w/out further doing
modifications to the system.

> The package was already split for lesser reasons (IMHO) to separate off the
> release docs, why not split off the repo config, too?
> 

fedora-release-notes was split off because it came from a completely different
CVS module, had a completely different generation toolchain, and had different
release needs.

I'm not interested in continuing to argue about this in a bug report.  As the
maintainer of the package, I do not wish to implement this feature request, nor
do a few of the technical leads of Fedora Core.  If you really want it this way,
do it yourself in your repo like you do a lot of other things you see fit to do.

(In reply to comment #14)
> > > Also, without hand modifying the config files, how
> > > do you prevent the next fedora-yumconfig package issued by Fedora from
> > > overwriting your replacement package files?  Are you going to so some
> > > trickery
> > > with epochs?  Asking users to excludepkg from configs, etc..?
> > 
> > No, why should one do such nasty things? Just check out how smart and apt
> > work. They already have this idiom in place.
> 
> The idiom to do what?  A newer package is available in a configured repo. 
> What idiom is automatically in place that states "do not update this package,
> its speshul"?

It's basic packaging Provides/Requires/Conflicts, no epochs or any other
unorthodox way. fedora-release requires yum-config or something similar which
can be fullfilled by both a vendor shipped package as well as an alternative
extarnal package. In order to avoid having both packages installed at the same
time the alternative package explicitely conflicts with the vendor shipped.

That's all. Note that there is no Obsoletes involved, which means that the
alternative package *only* replaces the vendor shipped one upon *explicit*
request, not automatically. It's a clean solution.

> > > Why aren't your mirrors listed in the official mirror list,
> > 
> > That's one of the main PITA, they *ARE* official mirrors. But even *the
> > servers
> > themselves* don't get redirected to themselves ...
> > 
> > > The solution is to fix the mirroring system, not replace it wholesale.
> > 
> > That's orthogonal, and the user complaints are there and need to be taken care
> > of now. If in the future the mirror system works better some arguments on favour
> > of the split would drop, but it's not happening with FC6.
> 
> It _IS_ happening for FC6.  The development repo config files I shipped a short
> time ago make use of Geiop for correct mirror assignment.

Yeah, cool. So for my servers sitting in Berlin, Germany, Europe officially
hosting FC mirrors, current FC6's yum gives me sunsite.mff.cuni.cz. Not very
convincing IMO.

> The demand is you, and it costs overhead and complexity,

I can provide the small specfile patch needed. It's nothing complex.

> I'm not interested in continuing to argue about this in a bug report.  As the
> maintainer of the package, I do not wish to implement this feature request,
> nor do a few of the technical leads of Fedora Core.

OK, I can accept that. I outlined all details you needed, so at the end it's
your call, I can't force you.

> If you really want it this way, do it yourself in your repo

Is that an explicit consent of doing so outside of FC? I was trying to avoid
having repo maintainers and local site admins do such actions, this was all this
report is about.

Anyway thanks for reading.