policy: add pkgconfig rule #317
Conversation
|
Aren't these (mostly) redundant with the existing |
|
No, It is a pain to search package names that match build requirements.
|
pkgconfig entries in `develop/lib[<arch>]/pkgconfig` must be declared as `pc:*[_<arch>]`.
|
26 janvier 2025 à 12:01 "X512" ***@***.*** ***@***.***?to=%22X512%22%20%3Cnotifications%40github.com%3E > a écrit:
No, devel: entries often do not match pkgconfig names. Single devel package may also provide multiple pkgconfig entries.
It is a pain to search package names that match build requirements.
Can we fix devel: entries to match pkgconfig names? Or do they have to match something else? (they currently match library names, but I'm not sure they have to, or we can have two devel entries if the two disagree in a few cases).
One problem here is that every provide of every package is also copied into the main repository file (so that "pkgman install xxx" can find them there and work offline), so, adding more provides makes the package repo much larger.
So, if we can avoid having 90% of devel packages provide both a pc: and devel: entry with the same name, it would be nice to do it that way.
|
|
As can be seen in code above changed part,
By this logic we should also avoid long package descriptions or porting too much software, that is bad idea. Also without actually trying, we can't know how larger repo file will become, maybe not so much. It may be good idea to implement some kind of delta updates of repo file instead of fully downloading it on each run. Most of packages stay the same after repo update. |
|
26 janvier 2025 à 15:54 "X512" ***@***.*** ***@***.***?to=%22X512%22%20%3Cnotifications%40github.com%3E > a écrit:
As can be seen in code above changed part, devel: matches library name in develop/lib directory. But pkgconfig names don't necessary match library names. It can be header-only library that have no any libraries in develop/lib directory. It may be pkgconfig entry that refer multiple libraries. pkgconfig names are arbitrary and may be not consistent (may have or not have "lib" prefix etc.).
I know about the pkg-config situation. My question is more:
- Why do "devel:" entry have to match library names? Is that useful? Would it be a problem if we changed it to match pkgconfig files (when available)? I guess it is useful when your compiler says "-lxxx: library not found" and you want to install the matching package
- Second question, are pkgconfig files often identical with library names? If so, maybe we can use devel: entries for both. If most packages have a pkgconfig entry matching the library name, they get a single "devel:" entry also matching that. The few packages that have mismatches get two "devel:" entries. That is saving some space and processing time(maybe that saving is not large enough to be relevant) if a lot of libraries and pkgconfig files are matched. Otherwise, it's a bad idea, and introducing a separate namespace is better because it's cleaner and more explicit.
>
> so, adding more provides makes the package repo much larger.
>
By this logic we should also avoid long package descriptions or porting too much software, that if bad idea. Also without actually trying, we can't know how larger repo file will become, maybe not so much.
I'm just asking if we can reduce the problem in this one specific situation. If the answer is no, that is fine. but if the answer is yes, there is no reason to waste resources.
It may be good idea to implement some kind of delta updates of repo file instead of fully downloading it on each run. Most of packages stay the same after repo update.
Yes, there are other ways to improve this, of course.
|
|
I would be interested in examples of this. IMO we should not add more provides just for pkg-config files, at least in general (maybe there are specific cases where it makes sense). If the pkg-config file is just some other abbreviated form of the name then let's just make sure that abbreviated form appears in the package summary/description so |
Use case would be something like:
|
It will be better to specify |
|
No, I meant, what actually existing software has such .pc files that don't match either the software (package) name, or the library name? |
Can't give more example right not because I an currently not at home. |
|
The only one of those where the package name doesn't correspond to either the pkg-config name or library name is glvnd, and that does provide a |
|
x512 explained very clearly why this is needed:
"freetext" data in the description won't do it. First of all, it's clumsy (forcing people to write some specific words in the description, while we have metadata for it). Secondly, it's harder to parse and so would prevent making scripts or tools that automate things. For example, think of how Debugger can autoinstall needed debuginfo package. Surely an IDE may want to do the same, by scanning a buildsystem file or buildtool output, and automatically offering to install the needed development packages. For this to work, there has to be a predictable name related to what the buildsystem is looking for. This can be either a library name (if looking directly at -lxxx parameters in the linker command line), or a pkgconfig filename. For the same reason, storing that outside the repository file makes little sense: providing that information is exactly the job of the repository file. Another idea would be to rename the pkgconfig files. Unfortunately, doing so defeats their purpose, which is to have a predictable name to look for, no matter what platform you're in. So it's important that upstream pkgconfig names are kept. So the remaining options are:
|
|
The third option would be to not require a |
In that case I would expect a
In that case (but only in that case) it may make sense to have a separate provide. So, the policy check would then be that there is some provide matching the pkg-config name, or the pkg-config name with But if there are only a very small number of applications that fit that paradigm, like Lua, then a full policy check may not make sense and we should just add the provides for the particular packages as special cases. |
How it will work? Add some expressions support to pkgman like |
|
|
Dependency solver support specifying resolvable versions. |
|
Found pkgconfig files installed to wrong location while working on this: haikuports/haikuports#11694. |
pkgconfigentries indevelop/lib[<arch>]/pkgconfig/*.pcmust be declared aspc:*[_<arch>].This allow to easily install build dependencies for projects that use pkgconfig for locating dependencies.