[arch-general] Participation of Arch in Google Summer of Code.
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.
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.
On 2/19/19 7:20 AM, Michael Lojkovic via arch-general wrote:
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.
remakepkg invalidates .BUILDINFO and breaks reproducible builds as far as i can tell.
This is a terrible idea.
On Tue, Feb 19, 2019 at 14:10:34 +0100, Robin Broda via arch-general wrote:
On 2/19/19 7:20 AM, Michael Lojkovic via arch-general wrote:
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.
Author of remakepkg here. I think that adding such functionality to pacman would be a bit... backwards.
The forum thread on remakepkg explains why it was originally written; I hope it is somewhat clear why such a tool or functionality shouldn't really exist to begin with.
remakepkg invalidates .BUILDINFO and breaks reproducible builds as far as i can tell.
The semantics of .BUILDINFO in the context of remakepkg were unclear to me, so I chose to simply ignore it. Reproducible builds were not taken into account, so it's indeed very likely that it breaks that.
In the end, remakepkg is a hack. But the underlying concept itself is already a hack, so I'm not feeling too bad, to be honest :-)
(that being said, I'm obviously open for discussing suggestions)
Best, Tinu
On 2/19/19 10:19 AM, Tinu Weber wrote:
On Tue, Feb 19, 2019 at 14:10:34 +0100, Robin Broda via arch-general wrote:
remakepkg invalidates .BUILDINFO and breaks reproducible builds as far as i can tell.
The semantics of .BUILDINFO in the context of remakepkg were unclear to me, so I chose to simply ignore it. Reproducible builds were not taken into account, so it's indeed very likely that it breaks that.
In the end, remakepkg is a hack. But the underlying concept itself is already a hack, so I'm not feeling too bad, to be honest :-)
(that being said, I'm obviously open for discussing suggestions)
I see no problem and nothing to fix here. reproducible rebuilding a .pkg.tar.xz created by remakepkg, which has as its whole purpose, surgery upon a package, seems fundamentally unreproducible to me, moreover why would you want to reproduce it -- a reproducible rebuild of remakepkg packages should have as its only input, the original .pkg.tar.xz
On Tue, Feb 19, 2019 at 10:22:34 -0500, Eli Schwartz via arch-general wrote:
On 2/19/19 10:19 AM, Tinu Weber wrote:
On Tue, Feb 19, 2019 at 14:10:34 +0100, Robin Broda via arch-general wrote:
remakepkg invalidates .BUILDINFO and breaks reproducible builds as far as i can tell.
The semantics of .BUILDINFO in the context of remakepkg were unclear to me, so I chose to simply ignore it. Reproducible builds were not taken into account, so it's indeed very likely that it breaks that.
In the end, remakepkg is a hack. But the underlying concept itself is already a hack, so I'm not feeling too bad, to be honest :-)
(that being said, I'm obviously open for discussing suggestions)
I see no problem and nothing to fix here. reproducible rebuilding a .pkg.tar.xz created by remakepkg, which has as its whole purpose, surgery upon a package, seems fundamentally unreproducible to me, moreover why would you want to reproduce it -- a reproducible rebuild of remakepkg packages should have as its only input, the original .pkg.tar.xz
I was thinking more of: "If I run remakepkg twice on the same package, with the same rules, do I get the same output package?".
I just checked, and I do indeed modify the timestamp of a file when patching it (both the file itself and its MTREE entry), and I don't respect SOURCE_DATE_EPOCH, so I would conclude that remakepkg does not produce reproducible .pkg.tar.xz files.
Kind Regards, Tinu
On 2/19/19 11:26 AM, Tinu Weber wrote:
On Tue, Feb 19, 2019 at 10:22:34 -0500, Eli Schwartz via arch-general wrote:
On 2/19/19 10:19 AM, Tinu Weber wrote:
On Tue, Feb 19, 2019 at 14:10:34 +0100, Robin Broda via arch-general wrote:
remakepkg invalidates .BUILDINFO and breaks reproducible builds as far as i can tell.
The semantics of .BUILDINFO in the context of remakepkg were unclear to me, so I chose to simply ignore it. Reproducible builds were not taken into account, so it's indeed very likely that it breaks that.
In the end, remakepkg is a hack. But the underlying concept itself is already a hack, so I'm not feeling too bad, to be honest :-)
(that being said, I'm obviously open for discussing suggestions)
I see no problem and nothing to fix here. reproducible rebuilding a .pkg.tar.xz created by remakepkg, which has as its whole purpose, surgery upon a package, seems fundamentally unreproducible to me, moreover why would you want to reproduce it -- a reproducible rebuild of remakepkg packages should have as its only input, the original .pkg.tar.xz
I was thinking more of: "If I run remakepkg twice on the same package, with the same rules, do I get the same output package?".
I just checked, and I do indeed modify the timestamp of a file when patching it (both the file itself and its MTREE entry), and I don't respect SOURCE_DATE_EPOCH, so I would conclude that remakepkg does not produce reproducible .pkg.tar.xz files.
That's a fair point. If you wanted to have remakepkg be a program that supported reproducible builds, it would need to respect some form of SOURCE_DATE_EPOCH -- I suggest using the builddate that the original .pkg.tar.xz used.
As well, provide some mechanism for https://reproducible-builds.org/docs/recording/ the input (the .pkg.tar.xz and the deviations that have been declared).
The difference is that it is hardly an issue if remakepkg invalidates the makepkg .BUILDINFO spec, since remakepkg is not makepkg and isn't expected to produce the same output as makepkg anyway -- it is only meant to produce output that *pacman/libalpm* can consume.
On 2/19/19 4:19 PM, Tinu Weber wrote:
Author of remakepkg here. I think that adding such functionality to pacman would be a bit... backwards.
remakepkg invalidates .BUILDINFO and breaks reproducible builds as far as i can tell.
The semantics of .BUILDINFO in the context of remakepkg were unclear to me, so I chose to simply ignore it. Reproducible builds were not taken into account, so it's indeed very likely that it breaks that.
You could hotpatch it, but that's dirty. :P
In the end, remakepkg is a hack. But the underlying concept itself is already a hack, so I'm not feeling too bad, to be honest :-)
(that being said, I'm obviously open for discussing suggestions)
I'm sure it's useful, but as you acknowledged yourself it's kinda unfit for pacman/makepkg inclusion.
I don't have an issue with the tool itself as far as this discussion goes :)
Best, Tinu
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.
participants (5)
-
Aniket Pradhan
-
Eli Schwartz
-
Michael Lojkovic
-
Robin Broda
-
Tinu Weber