Possible problems to deal with, when locking a pkg to prevent updating

k.jacker

k.jacker

Hei,
I'm on FreeBSD 11.2-RELASE-p4 using pkg (on my laptop and my workstation).

Recently I upgraded all packages and was very unhappy with how german/mediathekview had changed in version 13.2.1.
The interface had undergone such big changes, that it really sucked and I reverted to the last good version 13.0.6.
(It's for searching through a huge list of german tv-streams, that can then be watched then, via your favorite videoplayer)

I wonder what problems I may run into in the future if I don't update it?
Code: 
% pkg lock -l
Currently locked packages:
de-mediathekview-13.0.6

Further, I thought about keeping an eye on the mediathekview projects homepage, to see if future upcoming version are worth a new try,
but for now it's seems it will become very bloated. (though bloaded might be ok for me, but the interface in the current state is almost unusable)
Anyway, is it possible to somehow try out future versions and keep my good old version 13.0.6, in case I still don't like the new version?

(To get back the old version, I downloaded ports.txz from 11.2-RELEASE which had version 13.0.6, buildt a package from it and installed that via pkg add ... on my laptop and workstation)
 
k.jacker said:
I wonder what problems I may run into in the future if I don't update it?
Click to expand...
Well, not that much I think...

Code: 
$ make run-depends-list                                                        
/usr/ports/java/openjfx8-devel
/usr/ports/multimedia/flvstreamer
/usr/ports/multimedia/mpv
/usr/ports/java/openjdk8
It mostly relies on Java, which is good news because Java runtimes (and libraries) are often (but not always!) quite reliable when it comes to backwards compatibility. However, I do recommend grabbing the source code of the previous version (if possible) because it might be required to rebuild that in the future whenever a library (or program) changes. Now hinting at multimedia/mpv for example.

But if no other package depends on this (check with pkg info -rx mediathek) then you should be safe with regards to package maintenance. Whenever you upgrade and suddenly notice that the system tries to de-install german/mediathekview (unlikely if you locked it) or complain about missing dependencies then you'll know it's time to either rebuild or, also possible, manually re-adjust its dependencies.

So maybe run pkg check --dependencies -x mediathek from time to time.

k.jacker said:
Anyway, is it possible to somehow try out future versions and keep my good old version 13.0.6, in case I still don't like the new version?
Click to expand...
Most definitely!

# pkg create -x mediathek, this would re-create the package based on your current installation and put the package file in the current directory. So you can then simply upgrade to a newer version, and if you don't like it then simply # pkg delete -x mediathek && pkg add ./<name of package>, and done.

Hope this can help!
 
ShelLuser said:
It mostly relies on Java, which is good news because Java runtimes (and libraries) are often (but not always!) quite reliable when it comes to backwards compatibility.
Click to expand...
That's good news!

I keep the sourcecode from 13.0.6 along with it's directory from the ports in a save place alrready and I will run pkg check --dependencies -x de-mediathekview from time to time as you suggest.

Nothing seems to depend on it, pkg info -rx mediathek shows nothing. Since I use the port now, I will probably build without flvstreamer and mpv in the future, to further reduce dependencies (I'm using it with mplayer).

ShelLuser said:
# pkg create -x mediathek, this would re-create the package based on your current installation and put the package file in the current directory. So you can then simply upgrade to a newer version, and if you don't like it then simply # pkg delete -x mediathek && pkg add ./<name of package>, and done.
Click to expand...
Got it! Now with your example, I finally understood what pkg(8) says about it, after rereading it :)

You helped me a lot, I'm happy now!
 
Phishfry said:
compile your application with STATIC_ARGS
Click to expand...
An interessting approach.
But as far as I understand the content of the thread you linked to, this is about adding the C libraries to the binary itself to become one binary, is that right?
I could come up with some use cases for this as well :), but the application I'm dealing with here is written in Java, and I doubt that'll work.
If I'm not totally wrong, Java applications are compiled JIT by default, so it's not a binary.
 
You must log in or register to reply here.
Back
Top