[csw-maintainers] file conflicts and the future...

[Ben Walton]

Hi All,

In developing the web integration code (almost done), I need to deal
with packages that might contain a file that conflicts with another
package.

Traditionally, this has not been allowed.  Do we consider this
tradition worth maintaining?

There are a few cases where a file might conflict with another
package:

1. Packages that provide similar functionality that is accessed
   through the a common name (imapd or sendmail).

2. Related packages that provide build support files (.so, .h) for
   various alternate program versions.

3. Unrelated programs that happen to ship a file with the same name.

The first case can be handled (now) with alternatives and I think
that's a good solution.

The second case is not as easy to handle with alternatives and we've
previously agreed (if memory serves) that it's not a good idea to try
handling that way.  That leaves either namespacing via the filesystem
or declaring the packages incompatible.

The third case could be handled with alternatives at the technical
level but that doesn't make sense as the conflicting files don't
provide similar/workalike functionality.  This would lead to a case
where either a renamed file (which might make it deviate from other
platforms) or an incompatible declaration are required.

My question to you is: Are people comfortable moving to a system where
declaring a package incompatible with another package is sufficient to
deliver conflicting files or should we stick to the traditional "1
file, 1 package" mechanism?

Although this question is mostly driven by "how should I write the
code to deal with this" it's also a general issue that can (and
does[1]) arise in non-error situations.

Packages in the current set of "to register" (changes since the last
manual run) with conflicts are:
berkeleydb3_dev
gcc4objc
gcc4g++
gcc4core

I think the first is the result of not removing an older package
(devel -> dev) and the gcc4 packages require an update of the older
gcc3 packages to correct.  The first will most likely disappear but
the gcc4 packages will retain the conflict until gcc3 is cleaned up.

If I exempt those packages from generating exceptions during the
unique file registration, I can now successfully register all changes
since the last manual run.

Thanks
-Ben

[1] http://lists.opencsw.org/pipermail/maintainers/2011-February/014160.html
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302