FS#10246 - proposal for building of optional doc packages
Attached to Project:
Pacman
Opened by Emanuele Rusconi (EmaRsk) - Monday, 21 April 2008, 22:41 GMT
Last edited by Dan McGee (toofishes) - Saturday, 17 January 2009, 17:07 GMT
Opened by Emanuele Rusconi (EmaRsk) - Monday, 21 April 2008, 22:41 GMT
Last edited by Dan McGee (toofishes) - Saturday, 17 January 2009, 17:07 GMT
|
Details
Summary:
Proposal of implementation for automated building of optional doc packages, instead of removing the docs. Motivation: Many users (me included) feel uneasy about the decision to strip the doc from the packages by default, as can be argued from the many forum threads about this topic. It has been suggested (http://bbs.archlinux.org/viewtopic.php?id=47434) to start a community project to deliver the missing docs, but it is my opinion that it would be an absolute overkill and a "dirt" solution. Details: My proposal is to modify makepkg to make it build, along with $pkgname-$pkgver-$pkgrel-$CARCH.pkg.tar.gz, also $pkgname-$pkgver-$pkgrel-$CARCH.doc.tar.gz, containing the otherwise rm'ed docs (if present). I attach a patch for makepkg to better show my idea of implementation. The pacman command would need to implement the option "--withdocs", that downloads and installs also the .doc.tar.gz (if available). Said option should work also with the -U option (used in makepkg): in this case the .doc.tar.gz (if present) should be in the same folder of the .pkg.tar.gz . makepkg.conf would require an additional DOCEXT='.doc.tar.gz' default, if not coded in the makepkg script. PROs: + backwards compatible + installation of the documentation for binary packages optional and off by default (no impact on Arch guidelines/philosophy) + bandwidth saving for users and repo servers: one could just install the extra docs if/when needed, without the need to download the whole source + no extra work for the package maintainers (no need to modify the PKGBUILDs or do extra work by hand) + no need to repackage the whole repos: old packages would be still ok, while newer packages would come with an extra small - if present at all - tarball + overhead in terms of bandwith, hd space and cpu cycles for the maintainers substantially unnoticeable CONs: - the pacman program needs modifications, and though I imagine they would be quite easy for its maintainer, I haven't the necessary know-how to submit a working patch - I am not aware of possible complications e.g. for the repos administrations or weird interactions with other tools, it seems to me that it would be transparent but I cannot say for sure An alternative implementation could be to build $pkgname-doc-$pkgver-$pkgrel-$CARCH.pkg.tar.gz just as a regular package. That would have be easier to implement - no need to modify anything except makepkg - but would be, I think, much less clean and transparent both on the user and on the maintainer side. I hope to have not bothered anybody, but as this topic is often raised in the forums, and as I think that the idea I propose here would be clean and not difficult to implement, I really hope that the developers would take it into consideration. P.S.: I would like to write in a kinder manner, but I'm tired and sleepy and English is not my mother language. I assure you that I came with the friendliest attitude :) P.P.S.: I didn't really test the patch, as in this stage is only here for explaining purposes |
This task depends upon
Closed by Dan McGee (toofishes)
Saturday, 17 January 2009, 17:07 GMT
Reason for closing: Implemented
Additional comments about closing: See commit 3d49d88009341
Saturday, 17 January 2009, 17:07 GMT
Reason for closing: Implemented
Additional comments about closing: See commit 3d49d88009341
makepkg.patch
> $pkgname-doc-$pkgver-$pkgrel-$CARCH.pkg.tar.gz just as a regular package.
> That would have be easier to implement - no need to modify anything
> except makepkg - but would be, I think, much less clean and transparent
> both on the user and on the maintainer side.
Maybe that's just me, but I don't find your proposal clean at all.
Actually, I think that this alternative solution would be better.
But it still isn't ideal, because if you are going to split packages,
better do it a generic way, it would be much more useful.
See
FS#8187.What I find clean in solution #1 is that docs aren't packaged as regular packages, ergo
- they wouldn't need individual PKGBUILDs but would be built automatically when needed,
gradually replacing the stripped packages in the repos with no extra work (clean on maintainer's side)
- they wouldn't behave as separately installable packages but would be optionally installed with their "parent" packages (clean on user's side)
I would be interested to know what you don't find clean, feel free to send me a personal e-mail if you find it more appropriate.
@Aaron:
Yes, I and many others - from what I've seen in the forum - think so, but - as you know - we've been told very clearly that the developers (all?, many?, some?, it would be interesting to know) won't likely change the no_docs_by_default Arch's "feature", so I tried to find a solution that makes both sides happy, and with minimal effort.
Of course if the developers simply agree to stop stripping the docs, great! Even less work to do. ;)
That's funny, because that's exactly what I find ugly..
That is, it's not standard, not elegant and not transparent from pacman pov.
In my opinion, it is much more elegant to create regular packages that can be
handled normally by pacman..
Otherwise, I said earlier that it would be more useful to have a way to split packages.
While this has been indeed requested and discussed many times, it's worth mentioning that
splitting packages doesn't really fit with Arch standards and philosophy.
Finally, Aaron started a discussion to re-enable docs by default, and to let the choice
to arch developers / packagers :
http://archlinux.org/pipermail/arch-dev-public/2008-April/005913.html
But for some packages, the docs are MUCH bigger than all the rest.
In this case, it makes sense to keep stripping them and create a separate -doc package
(which could / should? be a community effort)
http://archlinux.org/pipermail/arch-dev-public/2008-April/005926.html
Hopefully, this should reduce the number of needed -doc packages to an acceptable amount.
Just to clarify, I'm not pushing :)
I'm glad to read from the discussion you linked that many developers are with the idea vanilla=no-strip, I didn't have the same feeling from the forum.
I'll watch how things will develop, hopefully this task will be obsolete soon :D
Thanks for the consideration, bye