Bug 158125

s/cpam/cman/

You need to install ccs.  It is standard procedure for the *-devel packages to
require their respective * packages.

> You need to install ccs.

Why? My build system is not in a cluster.

> It is standard procedure for the *-devel packages to
> require their respective * packages.

The standard procedure is wrong then. It's not logical.  x-devel is required for
development. It's needed on a development system. x is required for what
whatever x does, and might be appropriate for a server or a workstation, or a
whatever. 

Bogus dependencies just make "dependency hell" more common, and give RPM a bad
name. Please reconsider. Talk to Jeff or others.

Note, there may be an issue here with shared libraries. Shared libraries should
go into both packages, as they might be needed for development.

Re-opening, as I'm convinced it is a bug, and hope that you will reconsider.

We don't want to allow the user to accidently have differing versions of ccs &
ccs-devel on the same machine.  Also, if we end up using shared libraries then
we put symlinks to the shared libraries from the main package in the -devel package.

Which Jeff are you talking about?  I can get his opinion on this matter as well.

Closing bug as NOTABUG.

> We don't want to allow the user to accidently have differing versions of ccs &
> ccs-devel on the same machine.

I'd be interested to explore why not. Do they conflict?

> Also, if we end up using shared libraries then
> we put symlinks to the shared libraries from the main package in the -devel 
> package.

Why don't you put the shared libraries in both packages?

> Which Jeff are you talking about?  I can get his opinion on this matter as
> well.

I was thinking about Jeff Johnson, but you could also try Eric Troan.

You haven't said why you don't think it's a bug. You are forcing me to install a
package I don't need or want. That's a bug. Surely. (Yes, it seems to be a
widespread bug, but it's a bug nonetheless. The widespread nature of the bug
simply means that I will need to install multiple runtime packages on my
development only box, just to satisfy your dependencies.

In the general case where you have a shared library, the -devel/main requirement
is a real dependency where you put merely the libfoo.so symlink in the devel
package.

But it's also just to enforce consistency.  When I run "up2date foo" or "yum
update foo", I don't expect to have an old version of foo-devel left around (and
vice versa).

There's also an argument about interface versioning - Can you ensure that an
application built against libccs.a will be able to talk to the ccsd if the
-devel/main package versions aren't matched up?  Another good reason to enforce
the requirement.

> In the general case where you have a shared library, the -devel/main requirement
> is a real dependency where you put merely the libfoo.so symlink in the devel
> package.

Why? Why can't you put the shared library in both packages? Why force foo if you
only want foo-devel?

> When I run "up2date foo" or "yum update foo", I don't expect to have an old 
> version of foo-devel left around (and vice versa).

OK, so you add "Obsoletes: foo-devel < n.n" to foo.

> There's also an argument about interface versioning - Can you ensure that an
> application built against libccs.a will be able to talk to the ccsd if the
> -devel/main package versions aren't matched up?  Another good reason to
> enforce the requirement.

Is that not an argument for including the .so in ccs-devel? It's also an
argument for putting protocol version information in the comms between said app
and ccsd. Or some other dependency information in the application RPM. Otherwise
what's to stop me installing ccs-devel (and ccs because you insist on it) one
day, compiling the app with static linking, then upgrading ccs (and ccs-devel
because you insist on it)? I'll be able to do it, but the apps won't talk.

To put it another way, what's the point in splitting foo-devel from foo, if you
can't install it separately? foo-devel content is guaranteed to be harmless if
you don't need it, but the same can't be said about foo.

> To put it another way, what's the point in splitting foo-devel from foo, if you
> can't install it separately? foo-devel content is guaranteed to be harmless if
> you don't need it, but the same can't be said about foo.

We split foo-devel off from foo so that if the user doesn't want to do
development they aren't required to have those extra packages.

> Why? Why can't you put the shared library in both packages? Why force foo if you
> only want foo-devel?

Putting the shared library in both places is a waste of space and can cause
problems if the libraries get out of sync with each other.

Virtually every other -devel package in RHEL is dependent on its main package.
The benefit of keeping all of the -devel packages as similiar as possible
outweighs the limited benefit of not having to install the main package while
building.  Closing this bug as WONTFIX.

> We split foo-devel off from foo so that if the user doesn't want to do
> development they aren't required to have those extra packages.

But you don't mind me being required to install (potentially dangerous) binaries
that I don't want, when I only want to develop.

> Putting the shared library in both places is a waste of space and can cause
> problems if the libraries get out of sync with each other.

It's only a waste of space in the packages, not in the installed system. RPM
will prevent the shared libraries from getting out of sync.

> Virtually every other -devel package in RHEL is dependent on its main package.

Doesn't mean any of them is right :-)

> Closing this bug as WONTFIX.

Oh well, can't say I didn't try. Thanks for listening.