Problem with granular port/package management

poorandunlucky

poorandunlucky

Hey,

so I use Poudriere to build my own ports, and it's awesome and all, but now I sometimes encounter a problem when I try to deal with individual packages...

For instance:

Code: 
[Fri Jan  5 2018 03:26:11.603] doge@M6500 /usr/ports/security # pkg remove kgpg
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 3 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
        kgpg-4.14.3_1
        kdeutils-4.14.3_2
        kde-4.14.3_1

Number of packages to be removed: 3

The operation will free 2 MiB.

Proceed with deinstalling packages? [y/N]: n
[Fri Jan  5 2018 03:26:26.437] doge@M6500 /usr/ports/security #

If I want to remove that particular program, I have to remove KDE4 altogether... Same thing if I want to install Mate because VLC-QT4 is a dependency for KDE4, and Mate wants VLC normal...

It's not a huge problem yet, but it's becoming increasingly annoying...

Can anybody help?

lebarondemerde ?
 
You're trying to remove a package that other packages depend on, so if you remove that package the others will fail, that's why they are removed too. In order to be able to remove it without problems you need to find a way to remove the dependency from the other packages. This typically involves rebuilding those with different options. But note that some dependencies simply cannot be removed or disabled.
 
SirDice: there's no easy way, huh?

This is terrible... I can't have KDE and Gnome installed at the same time because of VLC...

OK, sure, it's probably just a checkmark in one of the option files, but which, and ... I guess one of the easiest ways would be to install the packages manually, like to install KDE without the meta-port... That would take care of some of it, but ... There has to be a way to mitigate the usefulness or necessity of having dependency relationships to the ability to do what you want... Like an override or something...

I was thinking of that yesterday, are the PKG relationship database a SQL database or a flat file database?

How hard would it be to implement levels of dependency? Like there's build and run dependency, but the KDE4 meta package doesn't depend on the KDE Games meta port... There has to be a way for me to uninstall a game without uninstalling KDE4...

The package management system has to be rethought...
 
I think if you do a pkg delete -f only the particular port will be deleted and not it's dependencies. But the port will be reinstalled again with an update of the dependent port.
 
MarcoB said:
I think if you do a pkg delete -f only the particular port will be deleted and not it's dependencies.
Click to expand...
Yes, that should work. But note that this may break the other applications, there's typically a very good reason why package A is depending on package B.
 
poorandunlucky said:
OK, sure, it's probably just a checkmark in one of the option files, but which, and ... I guess one of the easiest ways would be to install the packages manually, like to install KDE without the meta-port... That would take care of some of it, but ...
Click to expand...
I suggest you start reading the various port Makefiles to see which option pulls in a specific dependency.

There has to be a way to mitigate the usefulness or necessity of having dependency relationships to the ability to do what you want... Like an override or something...
Click to expand...
This is already done using the port's options. You just haven't figured out how this works yet.
 
Start by individually checking the ports and "work your way up the tree" (as I like to call it). Let's focus ourselves on security/kgpg-kde4 as per the OP:

Code: 
unicron:/home/peter $ pkg info -rx kgpg
kgpg-4.14.3_1:
        kdeutils-4.14.3_2
unicron:/home/peter $ pkg info -rx kdeutils
kdeutils-4.14.3_2:
        kde-4.14.3_1
So here I established that kGPG is required by KDEUtils which in its turn is required by KDE (the meta package).

So then I go check the first direct requirement, and what do you know...

Code: 
unicron:/usr/ports/misc/kdeutils4 $ make showconfig
===> The following configuration options are available for kdeutils-4.14.3_2:
     ARK=on: Archiving tool Ark
     FILELIGHT=on: File system viewer Filelight
     KCALC=on: Scientific calculator KCalc
     KCHARSELECT=on: Character selector KCharSelect
     KDF=on: Disk usage tool KDiskFree
     KFLOPPY=on: Floppy formatter KFloppy
     KGPG=on: Encryption tool KGpg
     KREMOTECONTROL=on: KRemoteControl
     KTIMER=on: Countdown launcher KTimer
     KWALLET=on: Password manager KWallet
     PRINTMANAGER=on: Print manager
     SUPERKARAMBA=on: Widget framework SuperKaramba
     SWEEPER=on: System cleaner Sweeper
===> Use 'make config' to modify these settings
There it is: KGPG.

You mentioned VLC but... I don't quite see the problem there:

Code: 
unicron:/usr/ports/misc/kdeutils4 $ pkg info -rox vlc-qt
vlc-qt4-2.2.6_5,4
Origin         : multimedia/vlc-qt4
Required by    :
        phonon-vlc-0.9.1_1

Even so: just work your way up the tree, and you'll find the issue in no time. Or not :p
 
@poorandunlucky for a newbie it seems horrible. But you only have to notice a few things. After a short time it is no more a problem. make showconfig and make showconfig-recursive are always your friend.
 
MarcoB said:
I think if you do a pkg delete -f only the particular port will be deleted and not it's dependencies. But the port will be reinstalled again with an update of the dependent port.
Click to expand...

I'm not really affected by package removal, it's more package installation that causes problems... Like trying to install Mate, for example, will also remove the KDE metaport because there's a conflict between KDE using qt-vlc and Mate just plain vlc, so for pkg to install Mate with no conflicts, it has to remove KDE. If I try to install Gnome, Enlightenment, all the same thing, all for different, somewhat useless ports.

lebarondemerde said:
In regards to multimedia/vlc, you should be able to build it with Qt5 and Qt4 support at the same time. And, if IIRC you still have CLI support. But (IMO) you would be better with multimedia/mpv, or one of its derivatives or front-ends.
Click to expand...

The package's content doesn't matter as much as the package's name in these scenarios... I think there should be a deeper logic behind the packages, ports, especially with regards to dependencies.

SirDice said:
I suggest you start reading the various port Makefiles to see which option pulls in a specific dependency.

This is already done using the port's options. You just haven't figured out how this works yet.
Click to expand...

aye, Sir... ._.

ShelLuser said:
Start by individually checking the ports and "work your way up the tree" (as I like to call it). Let's focus ourselves on security/kgpg-kde4 as per the OP:

[...]

Even so: just work your way up the tree, and you'll find the issue in no time. Or not :p
Click to expand...

I know how that works, and I'm able to deal with Makefiles and forcing commands here and there, but when installing big things like desktop environments that I want to make available for other users, we're talking several hundred ports, times several different desktop environments.

To deal with this manually this way would be a huge undertaking. There has to be a way to do it in a logical and efficient manner, and in a way that can be easily replicated, applied to different scenarios... i.e.: I need a permanent solution to a problem that's going to be chronic.

I'm not even considering updating here... I'd have to do this every time I update the software? Yyyeah... no... *shakes head*

talsamon said:
@poorandunlucky for a newbie it seems horrible. But you only have to notice a few things. After a short time it is no more a problem. make showconfig and make showconfig-recursive are always your friend.
Click to expand...

I don't think you understand the problem, and get caught up in my semi-fictive examples...

----------

TrueOS/PC-BSD uses ... whatchamaycallit... Like their software packages are self-contained, a bit like on a OS X machine, no? Are they like that or do I remember incorrectly... Does anyone know how they do that?
 
poorandunlucky said:
How hard would it be to implement levels of dependency? Like there's build and run dependency, but the KDE4 meta package doesn't depend on the KDE Games meta port... There has to be a way for me to uninstall a game without uninstalling KDE4...
Click to expand...

Just disable the KDEGAMES OPTION...

EDIT:
BTW, what you are asking is exactly what META-ports are created to avoid. The idea is to need just one origin to install a complete complex software suite.

You can avoid that NOT using the META-port and handling everything manually, or at least the parts you want to not be handled by the META-port, because you can disable several sub-parts of the x11/kde4 (disabling its OPTIONS).
 
I don't know why everybody is getting stuck in specifics...

... I'm just like "whatever" at this point...

Those aren't even real examples... I'm just using those particular cases to illustrate a bigger issue... Maybe not an operating system issue, but an issue for me...
 
You must log in or register to reply here.
Back
Top