FS#10245 - proposal for building of optional doc packages

Attached to Project: Arch Linux
Opened by Emanuele Rusconi (EmaRsk) - Monday, 21 April 2008, 22:18 GMT
Last edited by Aaron Griffin (phrakture) - Tuesday, 22 April 2008, 01:59 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

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.

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 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 tarball, if present at all
+ 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

An alternative implementation could be to build $pkgname-doc-$pkgver-$pkgrel-$CARCH.pkg.tar.gz instead.
That would have be easier to implement: it would not 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  Aaron Griffin (phrakture)
Tuesday, 22 April 2008, 01:59 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#10246 
Comment by Emanuele Rusconi (EmaRsk) - Monday, 21 April 2008, 22:23 GMT
OOOOOpppppsssss
Sorry I'm a bit tired, I selected pacman but I forgot to switch.
Please ignore it, I'll resubmit properly

Loading...