You are not logged in.
I've been tossing up Windows themed packages on the aur to make the desktop resemble Windows 10. I kind of want to move it to split package, so it's easier to download and install all of the separate packages for the theme. The only issue I've run into is all of the packages involved aren't necessarily updated at the same time, or have the same version number. For instance the gtk theme is on v0.9, and icon theme is on v0.3. All of the packages involved come out of the same project, except for the cursor theme. I'm just wondering if anyone knows of a split package I could refer to as an example for having different version numbers on the individual packages, or how to go about it.
Offline
No. They used to be able to, but it was removed as not being useful.
Offline
Ah ok. So, I can't make a package made up of other packages with each having their own versioning scheme. Is there anyway to group aur packages, like Cinnamon is on the official repo?
**edit**
Hmm, everything from cinnamon has the same version number.
Last edited by zerophase (2016-01-31 04:44:07)
Offline
If the source files are in different archive files, then I suggest you simply create multiple PKGBUILDs. If everything is a single archive, then choose the main component and use its version number for the compilation.
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
You can create metapackages, which is a package that just depends on other packages.. Groups don't really work well in the AUR.
Offline
You can create metapackages, which is a package that just depends on other packages.. Groups don't really work well in the AUR.
Thanks, a metapackage does make the most sense in this case.
Offline
No. They used to be able to, but it was removed as not being useful.
I see.
I'd even open a bug for this, but I'm not sure which confusion Dave/Allan would be talking about.
If it was only not being used, I can 100% see use cases for that.
(in my case, I'd like to split the opencl part just like all the other packages in official repos, but I have to mix more releases of the driver and it seems dirty having to lie about versions)
Offline
That package has enough problems already; you don't need to add some lying number for a single source archive which contains *one* version of the whole kit and caboodle.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
It's not single source (though, I concede it may be difficult to notice on first sight).
I'm also not speaking for Vi0L0, so don't worry.
Long story short though, I require GL userspace from 15.12, and CL from 15.9. And pkgver for split packages seemed the best way to handle it.
Offline
Well, but that's *dynamically determined* overrides from an older version, so not only do you want a split package that contains elderly versions, you want to determine whether said pkgver is elderly at runtime?
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Uh, no. I'm just talking about the pkgver variable, not the function.
(then I guess like there might also be an use case for that, but that's not my call)
Offline
If the source files are in different archive files, then I suggest you simply create multiple PKGBUILDs. If everything is a single archive, then choose the main component and use its version number for the compilation.
I have the case (phc-intel) where the same source can build a stable and a testing variant, both result in different versions.
Because it is the same source, I wanted to make it a split package containing both variants, but it seems I have to make separate packages because packages in a split package cannot contain differing `$pkgver`s.
Regards!
Offline
There's nothing special about phc-intel: all software has had multiple versions (except something compltely brand new with only a single initial release). Why would you want a PKGBUILD building multiple versions of the same software? That wouldn't even make a split package, just a duplicate package.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
There's nothing special about phc-intel: all software has had multiple versions (except something compltely brand new with only a single initial release). Why would you want a PKGBUILD building multiple versions of the same software? That wouldn't even make a split package, just a duplicate package.
In order to download source only once and to use some `PKGBUILD` code once, because many things are similar.
Yes, I get two packages then, one would have `-testing`/ `-unstable` within it's name, those packages would conflict each other, so only one of them is to be installed.
And there is a third package that would contain helper scripts, those scripts are the same for all versions, and ideally I want to include them in a split package together with the kernel module. But if I cannot put the stable and testing variant of the kernel module into one split package, then putting the scripts package into a split package with each kernel module would duplicate the scripts package.
Current solution is, though, to have three different packages; one for the stable variant of the kernel module, one for the testing variant of the kernel module, and one for the helper scripts.
All of them within the same package group.
Regards!
Offline
In order to download source only once
There's a simple solution for that, just set SRCDEST in makepkg.conf and makepkg will only download stuff one time and store it in $SRCDEST .
See https://wiki.archlinux.org/title/Makepk … tion_times
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline