| View previous topic :: View next topic |
| Author |
Message |
lars_the_bear
Guru
Joined: 05 Jun 2024
Posts: 522
|
 Posted: Thu Jun 20, 2024 8:43 am Post subject: Dependency versions in .ebuild files |
 |
|
Hi folks
I've set up a private overlay for my .ebuild files, so I can install my own stuff on multiple machines. So far it seems to be going well, but...
I'm wondering how to define dependencies. In particular, how to define specific versions of dependencies. Almost everything I've written, for example, depends on libjpeg. Since this library changes only rarely (so far as I can see) I don't think it matters all that much which version is installed.
But what if it's something that changes rapidly? I can't practicably test with multiple versions; but if I specify a dependency on some particular version that I tested, I can see how that might cause problems for me later.
When I look at the 'official' .build files, there seems to be a lot of variability here.
Is there any official guidance on this?
BR, Lars. |
|
| Back to top |
|
 |
asturm
Developer
Joined: 05 Apr 2007
Posts: 9280
|
| Posted: Thu Jun 20, 2024 8:46 am Post subject: |
|
|
| Dependency versions are not about what you have tested with, but what the packages' build system requires. Sometimes packaging considerations also come into play. |
|
| Back to top |
|
|
lars_the_bear
Guru
Joined: 05 Jun 2024
Posts: 522
|
| Posted: Thu Jun 20, 2024 10:42 am Post subject: |
|
|
| asturm wrote: | | Dependency versions are not about what you have tested with, but what the packages' build system requires. Sometimes packaging considerations also come into play. |
Thanks; but this is software maintained by me, so I know what the build system requires. In the specific case of libjpeg, it just #includes jpeglib.h and links with '-ljpeg'; and gets whatever version is present. It may work, or it may not.
I feel reasonably confident, in this case, of just defining a dependency on libjpeg, and not giving a version -- I don't think libjpeg has changed in a make/break way for 20 years.
Some libraries, though, change quite frequently. I've come across versions in my testing that definitely don't work with my applications. libvlc, for example. I have an application that uses libvlc -- it builds with versions after 3.0.14 or thereabouts, but it doesn't work properly until 3.0.19 (because, not that it's relevant, there's a bug with FLAC decoding until that version).
I don't know whether my application will work with 3.0.21, because it's not been released yet. I suspect it probably will.
So, as a dependency, I want to say something like 'vlc 3.0.19 or later'. I don't know how to specify that, but I guess it's documented.
But is that what people generally do?
What I'm really interested in is how (or whether) to specify a dependency version when I only know for certain that my application will build/run with a specific release of a library, but I strongly suspect that will will work with others.
BR, Lars |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22657
|
| Posted: Thu Jun 20, 2024 11:53 am Post subject: |
|
|
| Most Gentoo ebuilds take the optimistic assumption that upstream will not introduce regressions. Accordingly, the ebuild will specify a minimum version (vlc-3.0.19 in your case), and not a maximum version (because we have no reason to believe that vlc 3.0.21 will break it). If vlc-3.0.21 when released does break it, then an additional constraint can be added to the ebuild at that time. The policy may be different for upstreams that have a documented practice or a demonstrated pattern of routinely introducing regressions in newer releases. |
|
| Back to top |
|
|
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 227
|
| Posted: Thu Jun 20, 2024 12:43 pm Post subject: Re: Dependency versions in .ebuild files |
|
|
| lars_the_bear wrote: |
I'm wondering how to define dependencies. In particular, how to define specific versions of dependencies. Almost everything I've written, for example, depends on libjpeg. Since this library changes only rarely (so far as I can see) I don't think it matters all that much which version is installed.
But what if it's something that changes rapidly? I can't practicably test with multiple versions; but if I specify a dependency on some particular version that I tested, I can see how that might cause problems for me later.
|
See https://devmanual.gentoo.org/general-concepts/dependencies/index.html#version-dependencies for details on the supported syntax of an ebuild.
Per Gentoo policy, if the package link to -ljpeg and the jpeg package provides a "subslot", you should use https://devmanual.gentoo.org/general-concepts/dependencies/index.html#slot-operators if the jpeg package provides such a "subslot". The purpose of this is that if jpeg ever actually does decide to bump their ABI compatibility, portage will automatically rebuild your package at the same time -- and of course your package is still compatible with the jpeg headers so everything works.
There is no standard policy on what to do with ">=" dependencies or "<" dependencies other than "it should provide a good user experience". If the package upstream documents specific versions and its configure script checks for those versions, it's probably a good idea to use >= dependencies. If it will probably work but you haven't specifically and personally tested it, it's a "bad user experience" to require people to submit bug reports saying that portage won't even let them make the attempt to test it.
Most projects don't document the highest version of a dependency they support, because it's usually impractical to know that information in advance. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
