Closed Morganamilo closed 6 years ago
If this would be helpful to you then I'm not opposed to introduce these changes. I would just create a tag before merging such changes so people could pin an old version if desired.
Could you please specify the full definition of PKGBUILD
and PACKAGE
so it's more clear how it will look in the end? Either here as a comment or as a PR, whatever you prefer. Thanks!
I was just an example, I haven't really got a fully throught out system. Partly because I don't know know the full definition of a pkgbuild in the first place.man PKGBUILD
does give quite a lot of detail but there's still some stuff I'm not too sure on.
For example systemd-git
defines a pkgdesc inside each package() but also defines a pkgdesc globally. Which I think I think it should not be doing. The official systemd
pkgbuild in the repos does not do that.
I was just curious on your thoughts, personally I'm leaning on not worth it right now. Currently the way I get most of the pkg-info is through your aur project which does handle split packages just fine.
I'm just going to close this for now until something comes up that I need to do that can't be done currently.
Currently Support for split packages and multiple archs is quite limited. Pkg builds may define multiple source_ARCH arrays and we just end up dumping them all into a single array. Although that works fine, it does make it impossible to see what arch each source belongs to.
Another thing is each package in a pkgbase may have its own description yet the PKGBUILD Pkgdesc may only hold a single string. Also each package may define its own dependencies so if you were to install one package from a base it would be impossible to tell what that package actually does and doesn't need.
Changing everything to fully support multi arch and split packages might not be worth it to you, after all everything does work fine now and everything using this would need to adjust so I understand.
At the very least I would like to see Pkgdesc changed from string to []string but a better solution might be something more like.
Of course that does not solve that arch problem but I think would work well for split packages.