Solved Qt5 and libpq11 conflicts

jronald

jronald

1. pgsql11 on the Linux server
2. want to develop using pgsql C API to access pgsql11 on the server
3. libpq11 lib is going to delete Qt5:
Code: 
#pkg install postgresql11-client
Installed packages to be REMOVED:
    postgresql95-client-9.5.18
    qt5-sqldrivers-pgsql-5.12.2
    qt5-5.12.2_2

New packages to be INSTALLED:
    postgresql11-client: 11.4

How to solve the conflict? To install Qt5 by needed components instead of a meta pkg?
 
Packages use default settings, qt5-sqldrivers-pgsql depends on a PostgreSQL client. The default PostgreSQL version is 9.5. By installing postgresql11-client you are removing postgresql95-client and everything that depends on that 9.5 client, which includes qt5-sqldrivers-pgsql, which triggers the removal of qt5 because it depends on qt5-sqldrivers-pgsql.

jronald said:
How to solve the conflict?
Click to expand...
By setting the default PostgreSQL version to 11 and building from ports.
 
SirDice said:
Qt5 needs to be installed from ports
Click to expand...
I think you can get away with only rebuilding qt5-sqldrivers-pgsql as that has a direct dependency on PostgreSQL. QT5 itself just depends on qt5-sqldrivers-pgsql regardless of the PostgreSQL version.
 
SirDice said:
I think you can get away with only rebuilding qt5-sqldrivers-pgsql as that has a direct dependency on PostgreSQL. QT5 itself just depends on qt5-sqldrivers-pgsql regardless of the PostgreSQL version.
Click to expand...
This mixes pkg and ports. They say it's not perfect.
 
It isn't. Especially mixing quarterly packages with latest ports. But as long as you keep both at latest and are careful about your dependencies it's manageable. But there's definitely an inherent risk of ending up in a dependency hell.

The best way would be to build all your own packages and only install those. But this can be quite a time-consuming task.
 
SirDice said:
The best way would be to build all your own packages and only install those. But this can be quite a time-consuming task.
Click to expand...

Do you mean neither pkg nor ports?
The cost is that the custom-built application is better to have all its dependent libs in a custom place, so that it would not mix with pkg or ports.
If FreeBSD has an option that one application (including any dependecy) in one directory, that'll be perfect, and I will buy a bigger hard disk for that. :)
I have realized that the ports system is nice enough, just need a big hard disk, slow once is something paid for perfection. Thanks
 
SirDice said:
No, I mean using tools like ports-mgmt/poudriere or ports-mgmt/synth to set up your own package repository. Not the fastest way to update but it will give you the best of both worlds (flexibility from ports; ease of management from packages).
Click to expand...
Stuidied for a while, not very sure, ports-mgmt/poudriere or ports-mgmt/synth depends on /usr/ports/, they seems like optimization.
Can they solve this problem:
version of /usr/ports/editors/codelite is 12.0, but the newest official release version is 13.0. If codelite 13.0 is needed, does ports-mgmt/poudriere or ports-mgmt/synth help?
--------------------------------------------
To be simple, how to install an application that is not in pkg and ports?
I think I need a custom ports tree, using svn or git.
 
Ports build packages and it's those packages you actually install. These tools simply automate building packages from ports.
 
So for pkg or ports, dependency is carefully maintained, to add new port, the dependency should be reconsidered, right?
For example, many ports depends on postgresql 9.5,
then postgresql 12 released and I want to use it in my development,
but postgresql 9.5 and postgresql 12 CAN NOT coexist, so each port depends on postgresql 9.5 should be migrated to postgresql 12.

It's better if they can coexists.
It's even better if each application manages its own depency and libs can be shared like std::shared_ptr.
If I'm the designer, I'll put each application in one directory with ALL its dependencies, that's all. Everything else is optimaztion, e.g. only one copy of shared c runtime library in the system.
No matter how sophisticated the optimization is, it's only optimization, each application is still in one directory. The result:
  • copy a directory = install an application
  • delete a directory = unistnall an application
  • install with command = install an application with optimization
  • unstall with command = uninstall an application with optimization
 
jronald said:
If I'm the designer, I'll put each application in one directory with ALL its dependencies, that's all.
Click to expand...
From a security standpoint this is really bad and completely defeats the purpose of shared libraries. Suppose you have 3 or 4 applications installed this way, all three use "LibraryA". In your proposed solution I would need to update all applications individually because each has its own copy of the library. What if I forget one? How are you going to keep track of which application has the updated library and which doesn't? With a shared library I just need to update that one and can be sure all applications that use it have been fixed.
 
SirDice said:
From a security standpoint this is really bad and completely defeats the purpose of shared libraries. Suppose you have 3 or 4 applications installed this way, all three use "LibraryA". In your proposed solution I would need to update all applications individually because each has its own copy of the library. What if I forget one? How are you going to keep track of which application has the updated library and which doesn't? With a shared library I just need to update that one and can be sure all applications that use it have been fixed.
Click to expand...
It makes sense.

If one application agrees/needs the system to upgrade its lib(s), its installation program can make the lib(s) in a system place, and track it for uninstallation, any way it should still be optimization, the application is still in one directory.

If an application used a modified lib, and not allowed to be upgraded, for example add some redundant code to the lib to shift the exploit point for anti-hacking, it can choose to keep the lib, not allowed to be upgraded.

If an application link to a lib statically, the lib can't be upgraded by the system. Even worse the application itself can be insecure.

For an open system, easy evolving is important, copy/delete directory is really very very good for evolving.
 
You must log in or register to reply here.
Back
Top