You are not logged in.
I am new to arch (coming from Slackware) and I have am positively surprised. It keeps the simplicity of Slackware while providing a package repository. One of the thing I dislike is this idea to remove documentation. This is completely contradictory to the idea of leaving the software the way the original developer wishes and moreover doc is useful. I have heard that this policy have changed. Do anyone know what is it about? I still find gcc without doc and the default configuration for makepkg still remove doc (I know I can change this but I would like this to be changed by the people proving packages in the repositories).
Offline
There is pacman-3.2.0 in the [testing] repo which has the keeping of doc files by default. It will take a while but (most) packages will eventually be rebuilt with documentation added.
Offline
@Allan. I am very pleased to hear so. Arch is eventually approaching the "perfect" distribution I was looking for: distributing packages without putting a lot of fuss, bloat, buggy GUI configuration tools or patches (that we find almost everywhere).
Olive
Offline
Is there any problem to install packagename-doc when needed ?
Docs are great but imo should be kept in separate package (and installed as dependancy with option to override)
Offline
I also think that the docs should be optional.
(lambda ())
Offline
I have to jump on the "keep docs in the packages boat". What do those extra megabytes mean today ? It's always handy to have documentation available, is it not ? What if you needed to look up documentation for some app and you don't have internet access at the moment ? How are you supposed to obtain the doc package then ?
The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner.
--------------------------------------------------------------------------------------------------------------
But if they tell you that I've lost my mind, maybe it's not gone just a little hard to find...
Offline
The option to strip docs still exist in makepkg, it's just not the default anymore. Some packages will still have their docs in a separate package I think, for example gcc or emacs have a huge documentation that should not be mandatory.
If a package has too much documentation and you want to remove it, you can still rebuild it with the option to strip docs and install it.
Offline
The option to strip docs still exist in makepkg, it's just not the default anymore. Some packages will still have their docs in a separate package I think, for example gcc or emacs have a huge documentation that should not be mandatory.
If a package has too much documentation and you want to remove it, you can still rebuild it with the option to strip docs and install it.
Ok, so I'll have to rebuild a package just to remove the docs? It makes no sense.
Well, the packages are a .tar.gz. How hard would be to create a filter that installs all files but the ones that start with "/path/to/docs"?
(lambda ())
Offline
catwell wrote:The option to strip docs still exist in makepkg, it's just not the default anymore. Some packages will still have their docs in a separate package I think, for example gcc or emacs have a huge documentation that should not be mandatory.
If a package has too much documentation and you want to remove it, you can still rebuild it with the option to strip docs and install it.
Ok, so I'll have to rebuild a package just to remove the docs? It makes no sense.
Well, the packages are a .tar.gz. How hard would be to create a filter that installs all files but the ones that start with "/path/to/docs"?
For some people the issue is more about the download size than about the space on the disc.
But otherwise, your approach would be an improvement in my opinion, so feel free write a patch for pacman that makes this possible, I doubt that it'd be rejected.
Offline
I do have to ask what the point of including the docs is. Man pages are generally pretty comprehensive.
Offline
I do have to ask what the point of including the docs is. Man pages are generally pretty comprehensive.
Well in some cases upstream thinks it is a good thing to provide man pages, which are generated from --help output and puts some very good documentation into info docs.
Now who could that be? ![]()
Offline
Some people insist that docs should be optional. It can make sense if the docs have significant size. One good example is the texlive-doc (in community) for which the docs are over 300 Mb of size. But I am afraid of the "Debian way": we find zillons packages for every source packages and it is terribly difficult to have something that works because we never have installed the good packages.
But for now, for many packages, the docs was simply not available. This was the case for gcc (although someone have packaged it in the AUR) and tetex (although the docs are available for texlive).
Last edited by olive (2008-08-04 22:12:00)
Offline
Some people insist that docs should be optional. It can make sense if the docs have significant size. One good example is the texlive-doc (in community) for which the docs are aver 300 Mb. But I am afraid of the "Debian way": we find zillons packages for every source packages and it is terribly difficult to have something that works because we never have installed the good packages.
But for now, for many packages, the docs was simply not available. This was the case for gcc (although someone have packaged it in the AUR) and tetex (although the docs are available for texlive).
I agree with you. For packages that the docs are small, it will make little or no difference.
(lambda ())
Offline
@Gullible Jones. If the original author writes doc; I am in general sure it is worth reading. The info page gives in general a detailed manual while the man pages just gives the command line options. For example info gcc gives you the whole manual of gcc; info grub gives (or should give since it has also disappeared in arch) you the manual of grub (try understanding the possibilities of grub just reading the man pages).
Last edited by olive (2008-08-04 22:11:03)
Offline
Maybe an pacman config option would be a solution? Those who didn't want docs could set it, and pacman could just not copy the docs from the package. Having never looked over the pacman code, have no idea how difficult this would be. Maybe I'll have a delve.
blog - github - facebook - google profile
Offline
I do have to ask what the point of including the docs is. Man pages are generally pretty comprehensive.
Not always. Check the grub man page, for instance
Offline
Gullible Jones wrote:I do have to ask what the point of including the docs is. Man pages are generally pretty comprehensive.
Not always. Check the grub man page, for instance
Whoah! It's almost useless.
I have to jump on the "keep docs in the packages boat". What do those extra megabytes mean today ? It's always handy to have documentation available, is it not ? What if you needed to look up documentation for some app and you don't have internet access at the moment ? How are you supposed to obtain the doc package then ?
I don't know moljac, maybe because I for one, don't have lot of space in "/". Right now have 70% crap* in "/". Docs could fill a lot more.
*Of course not all of it is crap.
Arch - It's something refreshing
Offline
On my current computer I have to actively police my Linux partition to make sure it doesn't run out of space.
I'm curious how much more space my current set of packages will take up if all the doc files are included.
I don't think I've ever once looked at one on any distro I've run; so I'd certainly rather have the space for
other files.
If the doc files are all installed in a common folder I guess it would be possible to simply delete the contents
of the top level doc folder after every package install.
I'm not really that concerned, but in my case space *is* at a premium.
Offline
There is pacman-3.2.0 in the [testing] repo which has the keeping of doc files by default. It will take a while but (most) packages will eventually be rebuilt with documentation added.
Good on you. I discarded the last distribution I had been using (which was also the first distribution I ever used) because their policy on documentation was bassackward. I don't care very much about man pages, which are usually okay for a quick reference or to lookup command options and flags, but I do care about texinfo. If I install a package that would otherwise provide texinfo, it had better show up in Emacs after installation or I get crazy p*ssed off. Especially GNU packages, since texinfo is a requirement to be accepted by GNU. If anyone doesn't want to have documentation, go delete it yourself, and don't make the rest of us jump through effing hoops to get documentation out of broken package builds.
Offline
I also like info files and the decision to include them. But I see a problem: It is not easy to package them correctly, at least for packaging beginners. The is a dir file in which packagers have to merge the entrys for the info files the package has using the install-info command.
I really do not know myself what would be the proper way to deal with this dir files if you have two of them -- one in /usr/share/info and one in /usr/info. I think there should be some guidelines in how to do that.
Last edited by Stefan Husmann (2008-08-05 21:53:35)
Offline
Its amazing this topic has never come up before. ![]()
Offline
Its amazing this topic has never come up before.
So let's not discuss the ifS but howtoS.
Offline
I really do not know myself what would be the proper way to deal with this dir files if you have two of them -- one in /usr/share/info and one in /usr/info. I think there should be some guidelines in how to do that.
It doesn't matter. To be uniform, you could put all your doc files in one and symlink them to the other. This is the way it is done for sake of consistency in the popular from scratch recipes.
Offline
I really do not know myself what would be the proper way to deal with this dir files if you have two of them -- one in /usr/share/info and one in /usr/info. I think there should be some guidelines in how to do that.
All info pages should go into /usr/share/info, just like man pages should go into /usr/share/man. My current guideline is to just delete the dir file in that directory which I realise is not quite right... So any package with info files is going to need a install-info calls in the install file.
Edit: I should add a prototype install file to the abs packages which does this...
Offline
Its amazing this topic has never come up before.
This is the first change regarding doc files that I've ever noticed so that's why I piped up.
As Allan suggests, I hope the doc files do find their way to a single common location.
That way people with space issues can easily delete them. I hate to be self-serving,
but I'm just adding my voice to the apparent minority of users without a lot of space to spare.
I honestly have no idea how much additional space we're talking on average so I guess I should do
a bit of investigation before crying about this.
Offline