[pacman-dev] makepkg patch to create $pkgname-docs package for docs
This patch is a proof of concept to create a separate package for docs file ($pkgname-docs) with an only PKGBUILD. Do you like it? --- scripts/makepkg.in | 111 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 108 insertions(+), 3 deletions(-) diff --git a/scripts/makepkg.in b/scripts/makepkg.in index 1125e85..0fa9015 100755 --- a/scripts/makepkg.in +++ b/scripts/makepkg.in @@ -414,6 +414,27 @@ installpackage() { fi } +installdocspackage() { + if [ "$INSTALL" = "1" -a "$SUDO" = "1" ]; then + msg "$(gettext "Installing docs package with pacman -U...")" + if [ "$INFAKEROOT" = "1" ]; then + FAKEROOTKEY2=$FAKEROOTKEY + unset FAKEROOTKEY + fi + sudo pacman $PACMAN_OPTS -U $PKGDEST/${pkgname}-docs-${pkgver}-${pkgrel}-${CARCH}.${PKGEXT} + local exitcode=$? + if [ "$INFAKEROOT" = "1" ]; then + export FAKEROOTKEY=$FAKEROOTKEY2 + unset FAKEROOTKEY2 + fi + exit $exitcode + elif [ "$INSTALL" = "1" -a "$EUID" = "0" -a "$INFAKEROOT" != "1" ]; then + msg "$(gettext "Installing docs package with pacman -U...")" + pacman $PACMAN_OPTS -U $PKGDEST/${pkgname}-docs-${pkgver}-${pkgrel}-${CARCH}.${PKGEXT} + exit $? + fi +} + usage() { echo "$(eval_gettext "makepkg version \$myver")" echo @@ -961,9 +982,90 @@ else fi fi -if [ "$(check_option docs)" = "n" ]; then - # remove info/doc files - msg "$(gettext "Removing info/doc files...")" + +if [ "$(check_option packdocs)" = "y" ]; then + msg "Packaging docs" + + rm -fr $startdir/pkg-docs + + cd "$startdir/pkg" + for ddir in ${DOC_DIRS[@]}; do + if [ -d $ddir ]; then + mkdir -p "$startdir/pkg-docs/$ddir" + mv $ddir/* "$startdir/pkg-docs/$ddir" + fi + done + + # remove docs from the master package + rm -rf ${DOC_DIRS[@]} + find -depth -type d -empty -delete; + + cd "$startdir/pkg-docs" + tar cvf /dev/null * | sort >.FILELIST + + builddate=$(LC_ALL= ; LANG= ; date -u "+%a %b %e %H:%M:%S %Y") + if [ "$PACKAGER" != "" ]; then + packager="$PACKAGER" + else + packager="Arch Linux (http://www.archlinux.org)" + fi + + size=$(du -cb "$startdir/pkg-docs" | tail -n 1 | awk '{print $1}') + + # write the .PKGINFO file + msg "$(gettext "Generating .PKGINFO file...")" + echo "# Generated by makepkg $myver" >.PKGINFO + echo -n "# " >>.PKGINFO + date >>.PKGINFO + echo "pkgname = $pkgname-docs" >>.PKGINFO + echo "pkgver = $pkgver-$pkgrel" >>.PKGINFO + + # You may want to change this + echo "pkgdesc = $pkgname docs" >>.PKGINFO + + echo "url = $url" >>.PKGINFO + echo "builddate = $builddate" >>.PKGINFO + echo "packager = $packager" >>.PKGINFO + echo "size = $size" >>.PKGINFO + + # maybe put NOARCH or something similar? + if [ "$CARCH" != "" ]; then + echo "arch = $CARCH" >>.PKGINFO + fi + + # and which license? should docs package + # inherit master package license? (I don't think so) + # maybe we could add a docslicense var into the PKGBUILD + for it in "${license[@]}"; do + echo "license = $it" >>.PKGINFO + done + + # We could use a 'docs' group, or inherit master package group + for it in "${groups[@]}"; do + echo "group = $it" >>.PKGINFO + done + +# I don't think these are needed for a -docs package +# echo "replaces = $it" >>.PKGINFO +# echo "depend = $it" >>.PKGINFO +# echo "conflict = $it" >>.PKGINFO +# echo "provides = $it" >>.PKGINFO +# echo "backup = $it" >>.PKGINFO + + pkg_docs_file="$PKGDEST/$pkgname-docs-$pkgver-$pkgrel-${CARCH}.${PKGEXT}" + comp_files=".PKGINFO .FILELIST ${install:+.INSTALL}" + + msg "$(gettext "Compressing docs package...")" + if ! tar czf $pkg_docs_file $comp_files *; then + error "$(gettext "Failed to create docs package file.")" + exit 1 + fi + +elif [ "$(check_option docs)" = "n" ]; then +# maybe "else" instead of "elif" would be better? + + # remove info/doc files + msg "$(gettext "Removing info/doc files...")" cd "$startdir/pkg" #fix flyspray bug #5021 rm -rf ${DOC_DIRS[@]} @@ -1122,6 +1224,9 @@ msg "$(eval_gettext "Finished making: \$pkgname (\$date)")" installpackage +if [ "$(check_option packdocs)" = "y" ]; then + installdocspackage +fi exit 0 # vim: set ts=2 sw=2 noet: -- 1.5.1 -- Alessio 'mOLOk' Bolognino Arch Linux Trusted User Public Key @ http://themolok.netsons.org/uploads/themolok.asc Key ID = 1024D / FE0270FB 2007-04-11 Key Fingerprint = 9AF8 9011 F271 450D 59CF 2D7D 96C9 8F2A FE02 70FB
On Apr 23, 2007, at 1:38 PM, Alessio 'mOLOk' Bolognino wrote:
This patch is a proof of concept to create a separate package for docs file ($pkgname-docs) with an only PKGBUILD.
Just to clarify a bit: so say someone has the PKGBUILD for CVS and they build it and install with the docs options as "y" does it build just one package (CVS with the docs) or two packages (CVS and CVS' docs)? ~ Jamie / yankees26
On 15:52 Mon 23 Apr , James Rosten wrote:
On Apr 23, 2007, at 1:38 PM, Alessio 'mOLOk' Bolognino wrote:
This patch is a proof of concept to create a separate package for docs file ($pkgname-docs) with an only PKGBUILD.
Just to clarify a bit: so say someone has the PKGBUILD for CVS and they build it and install with the docs options as "y" does it build just one package (CVS with the docs) or two packages (CVS and CVS' docs)?
if docs=n and packdocs=n it build a package with the software only; if docs=y and packdocs=n it builds a package with the software and the docs; if docs=y and packdocs=y it builds two packages, one with the software and one with the docs; if docs=n and packdocs=y it builds two packages, one with the software and one with the docs. In this way the default behaviour doesn't change, so it shouldn't break anything. -- Alessio 'mOLOk' Bolognino Arch Linux Trusted User Public Key @ http://themolok.netsons.org/uploads/themolok.asc Key ID = 1024D / FE0270FB 2007-04-11 Key Fingerprint = 9AF8 9011 F271 450D 59CF 2D7D 96C9 8F2A FE02 70FB
I was under the impression that, at some point, all pacman packages would include docs by default but there would be a post_install hook in pacman whereby people could specify to strip docs (post_install="stripdocs" in pacman.conf or something similar). At least, I hope this is still the case ;) It's clean and gives users a lot of flexibility to perform additional tasks (e.g. strip unneeded locales). Scott
2007/4/24, Scott Horowitz <stonecrest@gmail.com>:
I was under the impression that, at some point, all pacman packages would include docs by default but there would be a post_install hook in pacman whereby people could specify to strip docs (post_install="stripdocs" in pacman.conf or something similar).
At least, I hope this is still the case ;) It's clean and gives users a lot of flexibility to perform additional tasks (e.g. strip unneeded locales).
Nah, stripping docs after downloading them is ...mm ...not good. ;-) I was long-time supporter for splitted packages though (-dev, -doc etc., you can see my comments about that idea in some bugreports). Though most packages don't contain anything really useful in docs, but some (e.g. for interpreters or libraries) are useful. I like Alessio's aproach to solving that -doc packages issue. -- Roman Kyrylych (Роман Кирилич)
On 4/24/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
Nah, stripping docs after downloading them is ...mm ...not good. ;-) I was long-time supporter for splitted packages though (-dev, -doc etc., you can see my comments about that idea in some bugreports).
I disagree strongly, but you probably already knew that ;) It seems ridiculous to me to have packages with just docs. What happened to KISS? I guarantee that the vast majority of users will either want all docs or want no docs, not some in between on a per-package basis. Having vanilla arch packages built with docs and allowing people to specify in their pacman.conf if they want them stripped is very logical. I sure hope Arch never goes the way of Debian, where every application is split into numerous packages. It's the thing I hate most about Debian-based systems. Just look at how many Ubuntu packages there are for the kernel - kernel-build, kernel-doc, kernel-headers, kernel-image, kernel-package, kernel-source, kernel-tree, kernel-wedge, linux-kernel-dev. What a headache :( Scott
2007/4/24, Scott Horowitz <stonecrest@gmail.com>:
On 4/24/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
Nah, stripping docs after downloading them is ...mm ...not good. ;-) I was long-time supporter for splitted packages though (-dev, -doc etc., you can see my comments about that idea in some bugreports).
I disagree strongly, but you probably already knew that ;) It seems ridiculous to me to have packages with just docs. What happened to KISS? I guarantee that the vast majority of users will either want all docs or want no docs, not some in between on a per-package basis. Having vanilla arch packages built with docs and allowing people to specify in their pacman.conf if they want them stripped is very logical.
I don't mind i.e. having php-docs merged into php package. :-) I just don't think stripping docs after downloading is really useful, because disk space is much cheaper than traffic cost and time. ;-) Using the same logic I could think about the option to strip *.h and *.a after downloading, because I don't compile anything on my server so I don't need them. Neither stripping docs nor *.h & *.a helps much _after_downloading_ becase (see above). The reason that we have -doc packages is that there was demand for some of them but since Arch doesn't ship docs - separate packages were created by people who wanted them. Now, include those docs in main package or still provide separate docs - not big deal IMO. -- Roman Kyrylych (Роман Кирилич)
On Mon, Apr 23, 2007 at 07:38:37PM +0200, Alessio 'mOLOk' Bolognino wrote:
This patch is a proof of concept to create a separate package for docs file ($pkgname-docs) with an only PKGBUILD.
Do you like it?
I know my opinion doesn't really matter in these cases, but... I would prefer to solve this much more generally than just creating a -docs package. If we're going to split packages, we might as well be able to split them any way we want. Jason
On 4/24/07, Jason Chu <jason@archlinux.org> wrote:
On Mon, Apr 23, 2007 at 07:38:37PM +0200, Alessio 'mOLOk' Bolognino wrote:
This patch is a proof of concept to create a separate package for docs file ($pkgname-docs) with an only PKGBUILD.
Do you like it?
I know my opinion doesn't really matter in these cases, but...
I would prefer to solve this much more generally than just creating a -docs package. If we're going to split packages, we might as well be able to split them any way we want.
I'm with Jason on this one- I like the idea of not needing multiple PKGBUILDs for packages that clearly can be generated from one, but we should extend this beyond docs. Think about kernel modules- those are a clear case for this as well. Responding to Roman- not to say you are wrong, but bandwidth has never been a concern for me and I feel like a lot of other users are the same way. We should keep that in mind with decisions though, although Arch has never been marketed as a distribution meant for those with slow connections- the idea of constant upgrading stomps on that. Finally, about the patch itself- if this was done, it should be functionalized, as I can see you duplicated a lot of code when generating the .PKGINFO file. You should be able to use the same code for both PKGINFO generations. In addition, I really dislike all the extra stuff (crud?) that has worked its way into makepkg- installing and removing deps, installing the package, etc. It is ugly that you had to make an extra installdocspackage function. It is almost to the point where the core makepkg functionality should be broken out. -Dan
On 13:04 Tue 24 Apr , Dan McGee wrote:
On 4/24/07, Jason Chu <jason@archlinux.org> wrote:
On Mon, Apr 23, 2007 at 07:38:37PM +0200, Alessio 'mOLOk' Bolognino wrote:
This patch is a proof of concept to create a separate package for docs file ($pkgname-docs) with an only PKGBUILD.
Do you like it?
I know my opinion doesn't really matter in these cases, but...
I would prefer to solve this much more generally than just creating a -docs package. If we're going to split packages, we might as well be able to split them any way we want.
I'm with Jason on this one- I like the idea of not needing multiple PKGBUILDs for packages that clearly can be generated from one, but we should extend this beyond docs. Think about kernel modules- those are a clear case for this as well.
Responding to Roman- not to say you are wrong, but bandwidth has never been a concern for me and I feel like a lot of other users are the same way. We should keep that in mind with decisions though, although Arch has never been marketed as a distribution meant for those with slow connections- the idea of constant upgrading stomps on that.
Finally, about the patch itself- if this was done, it should be functionalized, as I can see you duplicated a lot of code when generating the .PKGINFO file. You should be able to use the same code for both PKGINFO generations. In addition, I really dislike all the extra stuff (crud?) that has worked its way into makepkg- installing and removing deps, installing the package, etc. It is ugly that you had to make an extra installdocspackage function. It is almost to the point where the core makepkg functionality should be broken out.
This patch wasn't really intended for an immediately inclusion, but to open a discussion on the idea. Thanks for your suggestions. -- Alessio 'mOLOk' Bolognino Arch Linux Trusted User Public Key @ http://themolok.netsons.org/uploads/themolok.asc Key ID = 1024D / FE0270FB 2007-04-11 Key Fingerprint = 9AF8 9011 F271 450D 59CF 2D7D 96C9 8F2A FE02 70FB
On 4/24/07, Alessio 'mOLOk' Bolognino <themolok.ml@gmail.com> wrote:
This patch wasn't really intended for an immediately inclusion, but to open a discussion on the idea. Thanks for your suggestions.
Bringing this back up before things got WELL offtrack. I understand that we, Archlinux, have a position of docs and inclusion in packages, but that doesn't mean that pacman and makepkg must have the same position. I think this _IDEA_ is sound. But it's too general. There are 2 sets of patches on the bug tracker w.r.t. splitting packages. Is there any way, Alessio, that you could look at those and possibly make this more general? I think a "split package" solution is definitely needs - the ability to build more than one package at once from the same build file and potentially same/similar source. This case (docs as a separate package) falls into that realm. Opinions? - Aaron
2007/9/19, Aaron Griffin <aaronmgriffin@gmail.com>:
On 4/24/07, Alessio 'mOLOk' Bolognino <themolok.ml@gmail.com> wrote:
This patch wasn't really intended for an immediately inclusion, but to open a discussion on the idea. Thanks for your suggestions.
Bringing this back up before things got WELL offtrack.
I understand that we, Archlinux, have a position of docs and inclusion in packages, but that doesn't mean that pacman and makepkg must have the same position.
I think this _IDEA_ is sound. But it's too general. There are 2 sets of patches on the bug tracker w.r.t. splitting packages.
Is there any way, Alessio, that you could look at those and possibly make this more general?
I think a "split package" solution is definitely needs - the ability to build more than one package at once from the same build file and potentially same/similar source. This case (docs as a separate package) falls into that realm.
Opinions?
Thanks for bringing old threads to life, Aaron. :-) Yeah, I remember those other patches on bugtracker. It would be nice to have all threee merged into one solution. -- Roman Kyrylych (Роман Кирилич)
On 4/24/07, Dan McGee <dpmcgee@gmail.com> wrote:
Responding to Roman- not to say you are wrong, but bandwidth has never been a concern for me and I feel like a lot of other users are the same way. We should keep that in mind with decisions though, although Arch has never been marketed as a distribution meant for those with slow connections- the idea of constant upgrading stomps on that.
http://bbs.archlinux.org/viewtopic.php?id=22872 Arch may very well become (more) suitable for those with slow connections if this gets merged in the future :) But regardless, the bandwidth used by docs seems pretty negligible... Scott
On 4/24/07, Scott Horowitz <stonecrest@gmail.com> wrote:
On 4/24/07, Dan McGee <dpmcgee@gmail.com> wrote:
Responding to Roman- not to say you are wrong, but bandwidth has never been a concern for me and I feel like a lot of other users are the same way. We should keep that in mind with decisions though, although Arch has never been marketed as a distribution meant for those with slow connections- the idea of constant upgrading stomps on that.
http://bbs.archlinux.org/viewtopic.php?id=22872
Arch may very well become (more) suitable for those with slow connections if this gets merged in the future :) But regardless, the bandwidth used by docs seems pretty negligible...
Very true. I like the effort that has been put into this work, which is more than I would have put in, and it looks like it has real potential. On the second note (size of docs), has anyone done some size figures on a lot of these things? Taking a selection of packages and getting the sizes of the following things would be nice: Minimal package (binaries, libraries, /usr/share, etc.) Docs Locales Anything else that could be stripped (either during package builds or during install) -Dan
2007/4/24, Dan McGee <dpmcgee@gmail.com>:
On 4/24/07, Scott Horowitz <stonecrest@gmail.com> wrote:
On 4/24/07, Dan McGee <dpmcgee@gmail.com> wrote:
Responding to Roman- not to say you are wrong, but bandwidth has never been a concern for me and I feel like a lot of other users are the same way. We should keep that in mind with decisions though, although Arch has never been marketed as a distribution meant for those with slow connections- the idea of constant upgrading stomps on that.
http://bbs.archlinux.org/viewtopic.php?id=22872
Arch may very well become (more) suitable for those with slow connections if this gets merged in the future :) But regardless, the bandwidth used by docs seems pretty negligible...
Very true. I like the effort that has been put into this work, which is more than I would have put in, and it looks like it has real potential.
On the second note (size of docs), has anyone done some size figures on a lot of these things? Taking a selection of packages and getting the sizes of the following things would be nice: Minimal package (binaries, libraries, /usr/share, etc.) Docs Locales Anything else that could be stripped (either during package builds or during install)
OK, OK, let throw off bandwidth/size concerns. But then I'd like to see an option to strip *.h and *.a (which are pretty useless for users that never makepkg anything nor use aurbuild etc.) -- Roman Kyrylych (Роман Кирилич)
On Tue, 24 Apr 2007 23:46:55 +0300 "Roman Kyrylych" <roman.kyrylych@gmail.com> wrote:
OK, OK, let throw off bandwidth/size concerns. But then I'd like to see an option to strip *.h and *.a (which are pretty useless for users that never makepkg anything nor use aurbuild etc.)
There's a problem with stripping stuff needed for build - that "problem" is the AUR. Someone may never expect to need to compile, but then suddenly they realize this really neat or critical app is only available in the AUR - what happens when they set their option to strip away all these files? How do they get them back? This seems like it could be a big hassle. -- Travis
2007/4/28, Travis Willard <travis@archlinux.org>:
On Tue, 24 Apr 2007 23:46:55 +0300 "Roman Kyrylych" <roman.kyrylych@gmail.com> wrote:
OK, OK, let throw off bandwidth/size concerns. But then I'd like to see an option to strip *.h and *.a (which are pretty useless for users that never makepkg anything nor use aurbuild etc.)
There's a problem with stripping stuff needed for build - that "problem" is the AUR. Someone may never expect to need to compile, but then suddenly they realize this really neat or critical app is only available in the AUR - what happens when they set their option to strip away all these files? How do they get them back? This seems like it could be a big hassle.
The possibility that user that intentionally want to strip headers will _maybe_ need them in some distant future is not excuse, really. ;-) I think saying "hey, let's ship docs but have an option to strip them after install" and "option to strip headers is not good" is twofold. I don't understand such opinions, sorry... :-/ -- Roman Kyrylych (Роман Кирилич)
On Sat, 28 Apr 2007 13:02:10 +0300 "Roman Kyrylych" <roman.kyrylych@gmail.com> wrote:
The possibility that user that intentionally want to strip headers will _maybe_ need them in some distant future is not excuse, really. ;-)
It may not be an 'excuse' but it's a valid point - how _would_ people get these files back if they needed them? It will happen, do not doubt, and if the only solution is "edit your pacman.conf, remove the option, force-reinstall the package, then edit your pacman.conf to re-add the option" then I don't think that's a good enough solution.
I think saying "hey, let's ship docs but have an option to strip them after install" and "option to strip headers is not good" is twofold. I don't understand such opinions, sorry... :-/
My opinion about both is the same actually - shipping and stripping post-install is not a good idea. I don't know why you think I'm pro-stripping-docs - the email you responded to was my first message in this discussion. -- Travis
2007/4/28, Travis Willard <travis@archlinux.org>:
On Sat, 28 Apr 2007 13:02:10 +0300 "Roman Kyrylych" <roman.kyrylych@gmail.com> wrote:
The possibility that user that intentionally want to strip headers will _maybe_ need them in some distant future is not excuse, really. ;-)
It may not be an 'excuse' but it's a valid point - how _would_ people get these files back if they needed them? It will happen, do not doubt, and if the only solution is "edit your pacman.conf, remove the option, force-reinstall the package, then edit your pacman.conf to re-add the option" then I don't think that's a good enough solution.
I think saying "hey, let's ship docs but have an option to strip them after install" and "option to strip headers is not good" is twofold. I don't understand such opinions, sorry... :-/
My opinion about both is the same actually - shipping and stripping post-install is not a good idea. I don't know why you think I'm pro-stripping-docs - the email you responded to was my first message in this discussion.
Actually that part was not adressed to you personally. It was my fault to not state this explicitly. Take my apologies... :-( -- Roman Kyrylych (Роман Кирилич)
2007/4/24, Dan McGee <dpmcgee@gmail.com>:
On 4/24/07, Scott Horowitz <stonecrest@gmail.com> wrote:
On 4/24/07, Dan McGee <dpmcgee@gmail.com> wrote:
Responding to Roman- not to say you are wrong, but bandwidth has never been a concern for me and I feel like a lot of other users are the same way. We should keep that in mind with decisions though, although Arch has never been marketed as a distribution meant for those with slow connections- the idea of constant upgrading stomps on that.
http://bbs.archlinux.org/viewtopic.php?id=22872
Arch may very well become (more) suitable for those with slow connections if this gets merged in the future :) But regardless, the bandwidth used by docs seems pretty negligible...
Very true. I like the effort that has been put into this work, which is more than I would have put in, and it looks like it has real potential.
On the second note (size of docs), has anyone done some size figures on a lot of these things? Taking a selection of packages and getting the sizes of the following things would be nice: Minimal package (binaries, libraries, /usr/share, etc.) Docs Locales Anything else that could be stripped (either during package builds or during install)
For example on my server: /usr/include - 84M all *.a is /usr/lib - 65M /usr/share/locale - 89M my default locale (Ukrainian) - 1,8M -- Roman Kyrylych (Роман Кирилич)
participants (9)
-
Aaron Griffin
-
Alessio 'mOLOk' Bolognino
-
Dan McGee
-
James Rosten
-
Jason Chu
-
Nagy Gabor
-
Roman Kyrylych
-
Scott Horowitz
-
Travis Willard