View previous topic :: View next topic |
Author |
Message |
mauricev Apprentice
Joined: 22 Mar 2004 Posts: 202
|
Posted: Sun Apr 28, 2024 5:51 am Post subject: mysql and conflicting files |
|
|
The mysql ebuild is paired with the mysql-connector-c ebuild. I made new ones for mysql 8.3. When I emerge, mysql-connector-c complains about
Code: | * Detected file collision(s):
*
* /usr/bin/comp_err
|
How might these be handled? |
|
Back to top |
|
|
logrusx Veteran
Joined: 22 Feb 2018 Posts: 1694
|
Posted: Sun Apr 28, 2024 6:23 am Post subject: Re: mysql and conflicting files |
|
|
mauricev wrote: | The mysql ebuild is paired with the mysql-connector-c ebuild. I made new ones for mysql 8.3. When I emerge, mysql-connector-c complains about
Code: | * Detected file collision(s):
*
* /usr/bin/comp_err
|
How might these be handled? |
Two things:
1) why do you need the innovation version?
2) share the ebuilds;
And an extra thing: the innovation version is not meant to be stable in terms of features. It might be good for developers, but not for administrators and maintainers. You might be better off running it from your home directory. I don't think it needs root privileges.
Best Regards,
Georgi |
|
Back to top |
|
|
mauricev Apprentice
Joined: 22 Mar 2004 Posts: 202
|
Posted: Thu May 02, 2024 5:41 pm Post subject: |
|
|
I have some servers that use the "latest" docker image of mysql and that gave 8.3 (it now gives 8.4!), so I was going to apply the same version to plainly installed servers.
homebrew on the Mac also installs 8.3.
I found out I don't need mysql-connector-c, so I am no longer plagued with any conflicting files.
For the mysql 8.4 ebuild, I just commented out the patches and updated the src location, and it installed. |
|
Back to top |
|
|
logrusx Veteran
Joined: 22 Feb 2018 Posts: 1694
|
Posted: Thu May 02, 2024 6:14 pm Post subject: |
|
|
mauricev wrote: | I have some servers that use the "latest" docker image of mysql and that gave 8.3 (it now gives 8.4!), so I was going to apply the same version to plainly installed servers. |
So you don't know those servers really need the latest futures, right? I don't think there's something out there that requires it. It just doesn't make sense to release software that depends on something that might be of a production quality as Oracle claim on their site, but not stable feature wise.
I think you're just giving yourself unnecessary trouble.
BTW there are patches for 8.3, you just need to update their SRC_URI for them as well. But there was something else that was wrong I didn't want to dig into, given that this is the innovation version which is going to change very fast either way. And according to your words, it already changed.
Best Regards,
Georgi |
|
Back to top |
|
|
mauricev Apprentice
Joined: 22 Mar 2004 Posts: 202
|
Posted: Fri May 03, 2024 3:33 am Post subject: |
|
|
It turns out that I have one server depending on perl connecting to mysql and so I do need mysql-connector-c after all, which means I am back at square one in dealing with the conflicting files. How have the previous mysql ebuilds dealt with this?
Code: | BTW there are patches for 8.3 |
Where are they? I assume they're irrelevant now that 8.4 is out. |
|
Back to top |
|
|
logrusx Veteran
Joined: 22 Feb 2018 Posts: 1694
|
Posted: Fri May 03, 2024 6:49 am Post subject: |
|
|
mauricev wrote: | It turns out that I have one server depending on perl connecting to mysql and so I do need mysql-connector-c after all, which means I am back at square one in dealing with the conflicting files. How have the previous mysql ebuilds dealt with this?
Code: | BTW there are patches for 8.3 |
Where are they? I assume they're irrelevant now that 8.4 is out. |
Just adjust the version in the URI of the patches. You may as well replace it with ${PV}
p.s. the error I'm facing is related to C++20 and I'm not really up to fixing it:
Code: |
/var/tmp/portage/dev-db/mysql-8.3.0/work/mysql/mysys/lf_hash.cc: In function ‘int initialize_bucket(LF_HASH*, std::atomic<LF_SLIST*>*, uint, LF_PINS*)’:
/var/tmp/portage/dev-db/mysql-8.3.0/work/mysql/mysys/lf_hash.cc:851:37: error: ‘bit_floor’ is not a member of ‘std’; did you mean ‘bit_xor’?
851 | const uint parent = bucket ^ std::bit_floor(bucket);
| ^~~~~~~~~
| bit_xor
|
p.s.2 The source for 8.4.0 is 404. It seems not to be distributed the same way.
Best Regards,
Georgi |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 21867
|
Posted: Fri May 03, 2024 12:29 pm Post subject: |
|
|
logrusx wrote: | p.s. the error I'm facing is related to C++20 and I'm not really up to fixing it: Code: | /var/tmp/portage/dev-db/mysql-8.3.0/work/mysql/mysys/lf_hash.cc: In function ‘int initialize_bucket(LF_HASH*, std::atomic<LF_SLIST*>*, uint, LF_PINS*)’:
/var/tmp/portage/dev-db/mysql-8.3.0/work/mysql/mysys/lf_hash.cc:851:37: error: ‘bit_floor’ is not a member of ‘std’; did you mean ‘bit_xor’?
851 | const uint parent = bucket ^ std::bit_floor(bucket);
| ^~~~~~~~~
| bit_xor |
| std::bit_floor is new in C++20 (as you mentioned), and is provided by #include <numeric>. As I read cppreference: C++20 library features, both gcc and clang have supported this library feature for long enough that any currently supported compiler on Gentoo will support this, so the problem is likely just a missing #include. |
|
Back to top |
|
|
mauricev Apprentice
Joined: 22 Mar 2004 Posts: 202
|
Posted: Tue May 07, 2024 2:15 am Post subject: |
|
|
Simply changing
Code: | append-cxxflags -std=c++17 |
to
Code: | append-cxxflags -std=c++20 |
fixes it.
How can I trick portage into ignoring file collisions? For whatever reason, mysql-connector-c and mysql install a set of the same files. |
|
Back to top |
|
|
grknight Retired Dev
Joined: 20 Feb 2015 Posts: 1728
|
Posted: Tue May 07, 2024 12:29 pm Post subject: |
|
|
mauricev wrote: | How can I trick portage into ignoring file collisions? For whatever reason, mysql-connector-c and mysql install a set of the same files. |
Only because you stripped out the patch(es) that prevent this sort of thing. They exist for a good reason. |
|
Back to top |
|
|
logrusx Veteran
Joined: 22 Feb 2018 Posts: 1694
|
Posted: Tue May 07, 2024 3:44 pm Post subject: |
|
|
Had you shared your ebuild, I would have helped you fix it as soon as the first replay and this discussion would have been avoided.
Best Regards,
Georgi |
|
Back to top |
|
|
|