Bug 505729

Since when is it impossible to have more than one package own a directory? /usr/share/texmf should be owned by both texlive and gnuplot. If I recall well, gnuplot drops a tex file, and I think it is better to have it own /usr/share/texmf than having a dependency on texlive.

(In reply to comment #1)
> Since when is it impossible to have more than one package own a directory?

Since:
Transaction Check Error:
  file /usr/share/texmf from install of texlive-2008-0.1.fc11.x86_64 conflicts with file from package gnuplot-common-4.2.4-6.fc11.x86_64

> /usr/share/texmf should be owned by both texlive and gnuplot. If I recall well,
> gnuplot drops a tex file, and I think it is better to have it own
> /usr/share/texmf than having a dependency on texlive.  

Nope. You don't seems to get the point. In that case every -devel package should own %{_includedir} and similar nonsenses.

A proper solution is to create a subpackage shipping the tex file which depends on TeX. This is actually the only possible non-hackish solution.

Ivana, could you please update gnuplot BuildRequires to require tex(latex) instead of tetex-latex? tetex is gone for some time already and the tetex virtual provides are soon to be dropped what could break gnuplot build.

Thanks.

Created attachment 347899 [details]
Proposed gnuplot.spec change

Created attachment 347900 [details]
Proposed gnuplot.spec change with fixed directory ownership.

Thanks fixed in gnuplot-4.2.5-4.fc12 - thanks for the patch.

(In reply to comment #2)
> (In reply to comment #1)
> > Since when is it impossible to have more than one package own a directory?
> 
> Since:
> Transaction Check Error:
>   file /usr/share/texmf from install of texlive-2008-0.1.fc11.x86_64 conflicts
> with file from package gnuplot-common-4.2.4-6.fc11.x86_64

That's weird. And a big change. I relied on having directory not conflicting in many of my former packages.

> Nope. You don't seems to get the point. In that case every -devel package
> should own %{_includedir} and similar nonsenses.

That's what the filesystem package is for.

> A proper solution is to create a subpackage shipping the tex file which depends
> on TeX. This is actually the only possible non-hackish solution.  

I disagree. Although this is an acceptable solution, I think that doing a subpackage just for this file is pointless. It could make sense in other packages, but in this one, I don't think this is the right choice, at least not for the directory ownership reason.

Another solution would have been to excerpt from texlive the basic directory structure and have a texlive-filesystem (or better yet a tex(filesystem)) package.

In the end, is is up to Ivana to do the choice.


One point in favor of doing that subpackage is to explicit that some terminals won't work without LaTeX being installed, but this is different from doing it for the directory ownership issue.

Patrice,

actually you are very close to the way how the TL2008/9 packaging is done. The main texlive metapackage now contains and owns all of its directories (all dirs of the scheme-full) so it is a filesystem package equivalent. In the current state it contains a dependency on scheme-basic in TL though. This actually helped much to not to leave unowned dirs after TL removal but the directory ownership machinery still needs fixing on RPM side.

Just the fact that all TL directories are now owned by TL itself revealed this directory ownership problem. Given that the gnuplot.cfg shipped in the TEXMF tree is actually unusable without LaTeX it still makes perfectly sense to move it to subpackage and make it dependent on tex(latex) IMO.