On 05/07, Ralf Mardorf wrote:
On Sun, 5 Jul 2015 21:25:59 +0200, Marcel Korpel wrote:* Ralf Mardorf <[email protected]> (Sun, 5 Jul 2015 21:08:00 +0200):when using the AUR 4 search machine for "Name, Description" or "Name" and "Out of Date All", the keyword "lightscribe" does find "4l", but it doesn't find "lightscribe" and "lightscribe-labeler".The latter two are not in AUR4 yet, so package search doesn't find them. 4l has lightscribe in its description.When I searched for the packages they were in AUR 4, but the search engine didn't find them, that#s why I provided the links:
No, they were never uploaded to AUR4. They are in the DB due to how the package migration works, but they were never uploaded to AUR4 and won't show up in the search until they are.
Assumed for AUR 3 PKGBUILDs were available for 32-bit and 64-bit architecture, there were requests to make those split PKGBUILDs one for both architectures, does it make sense to provide the PKGBUILDs for AUR 4 with dropped 64-bit architecture and to provide 32-bit architecture only? We could argue that it's better somebody maintains 32-bit PKGBUILDs only, instead of completely dropping software, OTOH Arch claims to support 32-bit and 64-bit architecture and it looks like a step backwards to provide 32-bit architecture and to drop the newer 64-bit architecture.You can (and should) use separate source arrays, nowadays, so what do you mean by split packages?Will AUR 4 provide some PKGBUILDs only for 32-bit architecture and drop to continue providing those PKGBUILDs with multi-libs for 64-bit architecture too?
AUR4 provides a service. What users upload to it, it doesn't care about. And packages should build on 32-bit and 64-bit, whether as a lib32 package or not.
Assumed the maintainers decide to drop 64-bit support?
That sentence doesn't make any sense. -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
signature.asc
Description: PGP signature
