Summary: | dev-ml/findlib-1.9.3: conflict with dev-ml/ocamlbuild | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michael Orlitzky <mjo> |
Component: | Current packages | Assignee: | Gentoo Team for the ML programming language family <ml> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | eugene.shalygin, gentoo, gienah, m.lach2003, mail, psal, sam, till2.schaefer, wgh, yamadharma |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=831349 https://bugs.gentoo.org/show_bug.cgi?id=831371 https://bugs.gentoo.org/show_bug.cgi?id=803275 https://bugs.gentoo.org/show_bug.cgi?id=902839 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 901661 |
Right, it needs fixing properly. a trivial way to fix it is: emerge -C ocamlbuild num camlp4 emerge -a findlib ocamlbuild num camlp4 as META files are in all case produced by findlib, and the correct emerge sequence does not produce a collision. num and camlp4 are cited here because they raise the same problem If the 'tk' use flag is set the conflict extends to dev-ml/labltk as well. The proposed workaround does not work, since building findlib pulls dev-ml/labltk as a prerequisite, and re-triggers the conflict. To work it around it is sufficient to emerge findlib without 'tk' flag, and then re-emerge it with the flag set: # USE='-tk' emerge findlib # emerge findlib The second emerge does pull in dev-ml/labltk, but it apparently does not attempt to install the conflicting file (/usr/lib64/ocaml/labltk/META). Still bites at every emerge -u @world. Can we finally give dev-ml/ocamlbuild the same treatment that Sam gave dev-ml/camlp4 a few months ago [1]? This is breaking many emerge -u @world runs for me. [1]: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8cfd40d7cf6b67d78c9496ce0c0320562567e634 I just ran into the findlib/labltk file collision on /usr/lib64/ocaml/labltk/META today, and USE='-tk' emerge findlib as noted by Konrad in comment 3 does not seem to bypass the collision. I'll handle this later today. *** Bug 902711 has been marked as a duplicate of this bug. *** The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8e9aeadb5a60eea60b835c75ed81662ebec9e879 commit 8e9aeadb5a60eea60b835c75ed81662ebec9e879 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-03-22 07:26:52 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-03-22 07:35:30 +0000 dev-ml/findlib: workaround collision with labltk Bug: https://bugs.gentoo.org/803275 Closes: https://bugs.gentoo.org/833604 Signed-off-by: Sam James <sam@gentoo.org> dev-ml/findlib/findlib-1.9.3.ebuild | 5 ++++- dev-ml/findlib/findlib-1.9.5.ebuild | 5 ++++- dev-ml/findlib/findlib-1.9.6.ebuild | 3 +++ 3 files changed, 11 insertions(+), 2 deletions(-) Thanks for looking into it Sam, but there were TWO collisions reported here: 1) With labltk/META as reported in comments 3 and 6, 2) With ocamlbuild/META as reported by OP and remaining comments. Only case 1 was fixed so the bug needs to be re-open / re-worked. (In reply to Maciej S. Szmigiero from comment #10) > Thanks for looking into it Sam, > but there were TWO collisions reported here: > 1) With labltk/META as reported in comments 3 and 6, > > 2) With ocamlbuild/META as reported by OP and remaining comments. > > Only case 1 was fixed so the bug needs to be re-open / re-worked. Oh bugger, thanks. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=efbdf0b7351443045ef8ab23a03ea41dda0f94ae commit efbdf0b7351443045ef8ab23a03ea41dda0f94ae Author: Sam James <sam@gentoo.org> AuthorDate: 2023-03-22 10:16:16 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-03-22 10:16:16 +0000 dev-ml/findlib: remove ocamlbuild META too Closes: https://bugs.gentoo.org/833604 Signed-off-by: Sam James <sam@gentoo.org> dev-ml/findlib/findlib-1.9.3.ebuild | 2 +- dev-ml/findlib/findlib-1.9.5.ebuild | 2 +- dev-ml/findlib/findlib-1.9.6.ebuild | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) This also extends to camlp4 (see Bug 902839). I wonder if there are more error of the same kind. camlp4 was fixed in its ebuild, see [1]. [1]: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8cfd40d7cf6b67d78c9496ce0c0320562567e634 (In reply to Maciej S. Szmigiero from comment #14) > camlp4 was fixed in its ebuild, see [1]. > > [1]: > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=8cfd40d7cf6b67d78c9496ce0c0320562567e634 I think the condition on findlib >= 1.9 in that change is wrong. if you already have camlp4 and findlib 1.8.* installed, there is no way to upgrade without hard-removing camlp4. We need a special support for META files, this is unacceptable that we need special and exact emerge queue. My proposition is to do findlib_src_install then remove all META with > rm ${ED}/usr/$(get_libdir)/ocaml/*/META and THEN copy correct META file, this SHOULD be easy cause most of the time this is just > /usr/$(get_libdir)/ocaml/${PN}/META (In reply to Maciej Barć from comment #16) > We need a special support for META files, this is unacceptable that we need > special and exact emerge queue. > > My proposition is to do findlib_src_install then remove all META with > > rm ${ED}/usr/$(get_libdir)/ocaml/*/META > and THEN copy correct META file, this SHOULD be easy cause most of the time > this is just > > /usr/$(get_libdir)/ocaml/${PN}/META This sounds good. I'm sorry I haven't had a chance to sort it properly myself. |
>>> Installing (1 of 1) dev-ml/findlib-1.9.3::gentoo * checking 52 files for package collisions * ... * * Detected file collision(s): * * /usr/lib64/ocaml/ocamlbuild/META This doesn't happen with findlib-1.8.1-r2; I haven't tried v1.9.1.