On 2/19/19 1:20 AM, Michael Lojkovic via arch-general wrote:
On Sat, 2 Feb 2019 20:51:37 +0530 Aniket Pradhan <aniket17133@iiitd.ac.in> wrote:
Hello Govind, and Everyone!
Thanks for your feedback.
Your arguments are on point, and I agree with you on the fact that the ideas do not apply to Arch.
If we can think of some better ideas (which apply to Arch, like the reproducible builds or the CLI tool as you discussed) we would need people to step up and mentor these ideas out of their free time. Moreover, if Arch is willing to include some community tools (who decides which tools should be included), we might get some more cool ideas, but in the end, we would also need someone to mentor the idea.
In the end, it all boils down to the availability of mentors. and ideas.
I also had this cool idea, where developers (who will act as mentors) can pitch in their ideas for community packages and select students through GSoC. This will provide them with the necessary help in developing the tool. However, then it would not be a "community-driven" package, would it?
There can be several flaws to this suggestion, but as Govind said, it would be amazing if others can share their opinion on this topic.
The only thing I can think of, which applies to Arch is implementing remakepkg features in pacman. I was going to add those in when I got around to it, but it's also worth doing for Google Summer of Code.
You need the Google Summer of Code to implement an external tool that has already been implemented? Who told you to declare that this is definitively a desired, guaranteed-to-be-accepted feature, moreso that it is the only outstanding feature for the pacman project? We have 219 outstanding bug reports and feature requests, some of which would implement valuable safety features like aborting gracefully (rather than crashing after invalidating your system) if the user does something unwise like overwrite /var/cache/pacman/pkg with a symbolic link. "People want to know what they could do for Arch for GSOC", and you advertise some personal interest as being representative of the only thing you think Arch needs? When people have already mentioned things like pacman itself (see the aforementioned 219 bugtracker tickets), the build system and reproducible builds efforts, the security tracker... "The only thing I can think of which applies to Arch" is something no one has ever requested be added to makepkg, and furthermore -- it is out of scope. makepkg builds packages based on source code, remakepkg mutates existing ones in a manner that is not applicable to PKGBUILDs. makepkg can already --repackage your build directory with a modified PKGBUILD, if you ask it to, which is in scope for makepkg because it just involves picking up a makepkg build halfway through. Seems to me like remakepkg is already a perfectly suitable thirdparty tool that shares no commonality with makepkg, hence why it is a *thirdparty utility* -- and pacman is not the canonical provider of thirdparty utilities. Nor should it be -- if the primary "person who cares" about the tool does not regularly interact with the pacman-dev mailing list, the code would simply rot as part of pacman, and furthermore, even if it did see active development in the pacman tree, it would be forced to conform to the slower release cycle of pacman for no reason. -- Eli Schwartz Bug Wrangler and Trusted User