[arch-dev-public] Improving/Simplifying Kernel PKGBUILD
Some people liked this idea... http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/base/kernel26/PKGBUILD?rev=1.273&content-type=text/vnd.viewcvs-markup - We could put the patches into a patchset. tpowa has expressed dislike for this idea before, though it actually makes it easier to maintain. It'd allow the documentation to be moved out of the PKGBUILD, make the patches more accessible and the PKGBUILD cleaner. The only other things I can think of have alarm bells and are covered in red paint. Any other ideas? James
On Nov 12, 2007 7:19 PM, James Rayner <iphitus@gmail.com> wrote:
Some people liked this idea...
- We could put the patches into a patchset. tpowa has expressed dislike for this idea before, though it actually makes it easier to maintain. It'd allow the documentation to be moved out of the PKGBUILD, make the patches more accessible and the PKGBUILD cleaner.
The only other things I can think of have alarm bells and are covered in red paint. Any other ideas?
Would it be more clear to do something like: patches=(foo bar) sources=(blah ${sources[@]}) build() { .... for p in ${patches[@]}; do patch ...... done .... } Just a thought
On Nov 12, 2007 7:19 PM, James Rayner <iphitus@gmail.com> wrote:
Some people liked this idea...
- We could put the patches into a patchset. tpowa has expressed dislike for this idea before, though it actually makes it easier to maintain. It'd allow the documentation to be moved out of the PKGBUILD, make the patches more accessible and the PKGBUILD cleaner.
The only other things I can think of have alarm bells and are covered in red paint. Any other ideas?
Would it be more clear to do something like:
patches=(foo bar) sources=(blah ${sources[@]})
On Nov 13, 2007 12:16 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote: sources=(blah ${patches[@]}) :P
build() { .... for p in ${patches[@]}; do patch ...... done .... }
Just a thought
If we do the above, and then move all comments about the patches to a separate patches.list file where each could be explained, would that be smart? Or would that be weird (having a file in ABS/CVS that isn't actually needed for building a package). -Dan
On Nov 13, 2007 12:38 PM, Dan McGee <dpmcgee@gmail.com> wrote:
If we do the above, and then move all comments about the patches to a separate patches.list file where each could be explained, would that be smart? Or would that be weird (having a file in ABS/CVS that isn't actually needed for building a package).
Unless we cheat and actually use it for building... $ cat patches.list patches=( #this is a patch that does crap with things and stuff foo #here is another one bar ) /me shrugs
On Tue, 13 Nov 2007, Aaron Griffin wrote:
On Nov 13, 2007 12:38 PM, Dan McGee <dpmcgee@gmail.com> wrote:
If we do the above, and then move all comments about the patches to a separate patches.list file where each could be explained, would that be smart? Or would that be weird (having a file in ABS/CVS that isn't actually needed for building a package).
Unless we cheat and actually use it for building...
$ cat patches.list patches=( #this is a patch that does crap with things and stuff foo #here is another one bar )
/me shrugs
We could keep the comments for patches in the PKGBUILD but consolidate them in a single block that will be placed at the beginning or end of the PKGBUILD. At least, it would be better than having the source array and the build function cluttered by patches comments. Another solution would be to make use of pacman's Changelog functionnality. The patches could be commented in the Changelog upon addition. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
participants (4)
-
Aaron Griffin
-
Dan McGee
-
Eric Belanger
-
James Rayner