You are not logged in.
Pages: 1
Topic closed
Stripping the docs in order to have a light system seems to me like going on a morning run and expecting to run faster by omitting to take a handkerchief in your back pocket.
Sneeze, and you're the loneliest person in the world. ![]()
Just to say that I had to make a quick check in /usr/src/linux/DOCUMENTATION to setup my Intel High Definition soundcard, and... the docs weren't there. So I'm currently waiting for the whole shitload of linux-2.6.24.tar.bz2 to download from kernel.org on my 512 kbps DSL connection, just to check one line in the docs.
</rant>
Apart from that, I'm quite happy with Arch.
Dyslexics have more fnu.
Offline
Offline
The point of stripping the docs is to not have everything X times on your hard drive. Most of the time, the man pages are all you need and the info pages are simply a duplicate. As for kernel documentation: http://git.kernel.org/?p=linux/kernel/g … 623d0eb50f
Offline
I prefer having things x times on my harddrive, given that x does not exceed 4. At least PKGBUILS shold be written in such a way that they do not delete documentation explicitely but let the users decide if they want to keep the documentation ("docs" in makepkg.conf) or not ("!docs").
Gigabytes are cheap nowadays. I agree with kikinovak.
Offline
Agree!
Just because most of the time man pages are all you need, that does not imply that you'll never need anything else.
For example, this is what the man page for "diff" says:
The full documentation for diff is maintained as a Texinfo manual.
If the info and diff programs are properly installed at your site, the commandinfo diff
should give you access to the complete manual.
The same goes for a lot of core tools, because GNU people just favors info pages.
And often in the /usr/doc/<package> folder you could find configuration examples and other useful docs.
The stripping docs thing is the one thing that I dislike of Arch.
As Stefan said: "Gigabytes are cheap", but I'll add: "often cheaper than wasting time searching the web".
Offline
+1
Don't strip for paks with known bad man pages.
Offline
Before this gets ugly, just remember this topic has been covered many times for 5 years or more. At this time, Arch does not supply info pages.
A forum search will turn up the discussions over the course of time.
If Arch devs decide to stop stripping them, it will most likely happen gradually. ![]()
Offline
No-one could have predicted how *cheap* storage has now become. Saving 500mb of docs is zilch these days, it's not even a movie ![]()
Improve your desktop responsiveness and font rendering and ALSA sound and BusyBox init
Offline
Gigabytes are cheap nowadays.
Bandwidth and memory are very expensive for a lot of the world. Sure, if you live in a rich nation like I do, it's true. If one lives in a poor nation though...
Offline
this isnt changing.
search the forum.
Offline
"Search the forum"? Search wikipedia for the words "evolution" and "extinction". We don't have 500mb hard drives any more, we have 500 gigabyte drives.
Last edited by brebs (2008-04-21 13:01:40)
Improve your desktop responsiveness and font rendering and ALSA sound and BusyBox init
Offline
Search wikipedia for the words "evolution" and "extinction".
We have evolved past the want for info pages, and hence we have made them extinct in our packages. Little quips like this won't make us change our minds.
Offline
this topic has been covered many times for 5 years or more
Because it's annoying for a lot of people. If it is a so often raised topic, maybe it's worth to reconsider the decision. Maybe I'm exaggerating here, but I think the absence of proper docs is the main Arch show stopper for many people.
I'd like to see the packages split into "package" and "package-doc", for example, so I could spare disk and bandwith as usual but if I realize I need to read an info page I'd install the docs and voila.
It would be trivial to implement, just a line or two in the build scripts to tar the docs instead of throwing them away. No extra work for the package maintainers. Am I wrong?
Offline
The docs aren't there. There are a number of ways of dealing with this. It seems a lot of people like to start, and contribute to, threads like this one. IMO, that's the wrong way.
A quick review of Arch's history will show that the best way to get something that Arch does not provide by default is to do it yourself. In this case, the job is to create *-doc packages, set up a repo for them, and make it available to any Arch user that wants it. IMO, that's the right way. That's the way Arch64 started. That's the way KDEmod started, and continues to work.
Wouldn't it be great if the next thread on this topic was titled "Arch-doc repo now available"?
Offline
Little quips like this won't make us change our minds.
What will? Is it useless to provide logical reasons?
*-doc packages
Downloading e.g. a 10+ mb sourcecode tarball, for 20k of docs, is a horrible waste. Those docs were already in the sourcecode tarball that had to be downloaded to compile the package. Plus it's a separate package to keep in-sync, like with the annoyance of the separate nvidia and nvidia-utils packages.
So, -doc packages are not very palatable, but I agree they are the appropriate compromise if the devs are, ooh what's the word - unwilling.
Edit: Changed "un" word, for diplomacy ![]()
Last edited by brebs (2008-04-21 14:22:15)
Improve your desktop responsiveness and font rendering and ALSA sound and BusyBox init
Offline
What I was trying to say is that the *-doc packages could be made available with almost no extra work, no extra repo, no extra fuss. It's not nearly the same thing than porting to 64bit! Doing like you [tomk] say would mean duplicate a lot of work. The docs are already in the source: all is needed is to just not throwing them away.
As I already said, a few lines diff for makepkg and we could have both worlds for free.
I could write the diff, but if it'll never get accepted it's useless.
Offline
but if it'll never get accepted it's useless.
Actually worse than useless - it's soul-destroying. Which is why we suss out the devs' viewpoint first
And try to change the mindset for the better.
Last edited by brebs (2008-04-21 14:33:56)
Improve your desktop responsiveness and font rendering and ALSA sound and BusyBox init
Offline
Misfit138 wrote:this topic has been covered many times for 5 years or more
Because it's annoying for a lot of people. If it is a so often raised topic, maybe it's worth to reconsider the decision. Maybe I'm exaggerating here, but I think the absence of proper docs is the main Arch show stopper for many people.
I'd like to see the packages split into "package" and "package-doc", for example, so I could spare disk and bandwith as usual but if I realize I need to read an info page I'd install the docs and voila.
It would be trivial to implement, just a line or two in the build scripts to tar the docs instead of throwing them away. No extra work for the package maintainers. Am I wrong?
No, you are not 'wrong', but it is not a question of right or wrong.
You and Brebs are making your points in a frank and forthright manner, but the the devs have stated that they will not be providing these docs in the foreseeable time frame. If the community would like to change this, Aaron has even agreed to rsync the repos to the documented packages, but the key factor is that this will have to be a community effort.
If the community wants it, the community will have to provide a solution at this point. This is far from impossible.
The AUR, including the [community] repo is completely community-maintained. KDEmod, as was pointed out is 100% community developed. Yaourt, shaman, and pacman-contrib among others are all some of the strongest aspects of Arch.
Let's be pragmatic, proactive and as solution-oriented as possible. Either:
A) provide the docs in a repo or
B) Ask for the devs to stop stripping docs in a feature request on flyspray- maybe they will agree to simply stop stripping them and the docs will start to appear over time.
If the answer to B) is "no" then see A).
Offline
If our option in the end is "A", then may I suggest we start making a list of packages that need their docs file? So that we can have a clear idea of where to begin. Maybe creating a new thread to start a discussion on this.
Memento mori
Offline
If our option in the end is "A", then may I suggest we start making a list of packages that need their docs file? So that we can have a clear idea of where to begin. Maybe creating a new thread to start a discussion on this.
I'm afraid that for *every* package there is at least one person who wants (I wouldn't say needs) the docs for it locally. So if this is going to happen, I'd just start with everything core, then go on to extra...
As I already said, a few lines diff for makepkg and we could have both worlds for free.
Bandwidth and cpu cycles are never for free. If devs don't want to use their computing power to compress the docs and bandwidth to distribute them, it's their decision. They've already done a hell lot of work to bring us this wonderful distro, and I'm grateful for that. So why don't we shut up, stop demanding "more more more" and *do* something?
Offline
this will have to be a community effort
The key factor that makes this project different is that we are talking about packages that already have their maintainers, and setting up a new repo with separately maintained docs would be a truly inefficient way to do that:
I'm afraid that for *every* package there is at least one person who wants (I wouldn't say needs) the docs for it locally. So if this is going to happen, I'd just start with everything core, then go on to extra...
Offline
Misfit138 wrote:this will have to be a community effort
The key factor that makes this project different is that we are talking about packages that already have their maintainers, and setting up a new repo with separately maintained docs would be a truly inefficient way to do that:
bender02 wrote:I'm afraid that for *every* package there is at least one person who wants (I wouldn't say needs) the docs for it locally. So if this is going to happen, I'd just start with everything core, then go on to extra...
Of course I understand these factors. Again, let's be solution-oriented. Cooperate with the devs; Aaron is seemingly not against this in principle and has pledged to rsync the repos. Start out on flyspray in tactful language, requesting a halt on doc stripping. If a workable solution proves elusive, then the community providing the documents is a completely possible solution.
I am almost compelled to write up a feature request myself, on behalf of the community, but I must admit, I have never once used info pages.
Offline
Blah.... locking this as it has become inflammatory. I've said a million times that I'm more than welcome to do this, but someone needs to rebuild all the packages for me because I'm sure-as-hell not going to.
Offline
Pages: 1
Topic closed