Dear all, I have just had occasion to install the Statisitical Package "R", and was actually a bit disturbed to find that the License file had been removed. Together with some others of the files provided by the Package Authors to assist the user. Including of all things the names of the Authors. I do not believe that we have a duty to maintain this particular manifestation of the KISS principle. I regard it as vandalism on our part, and in the matter of the licence probably putting ourselves in breach of it. Whereas there may be a good reason to minimise the documentation provided with some utiities ( even though I disagree with that), when it comes to serious work type projects I think that policy should be given a serious rethink for every package, and in general, for the whole distro, It is crippling it. AND it is a lot of extra work to have to fix each Pkgfile to get the product in the form its authors intended. I have said this before, and will probably say it again. I just hope someone is listening. Clare Johnstone, Western Australia.
On 3/9/06, Clare Johnstone <claregj@gmail.com> wrote:
Whereas there may be a good reason to minimise the documentation provided with some utiities ( even though I disagree with that), when it comes to serious work type projects I think that policy should be given a serious rethink for every package, and in general, for the whole distro, It is crippling it. AND it is a lot of extra work to have to fix each Pkgfile to get the product in the form its authors intended.
I have said this before, and will probably say it again. I just hope someone is listening.
One of the principles of design in CRUX is to remove junk files. Files that you'll only (if ever) read once are, IMO, junk. Since CRUX is source based, you already have a local copy of the source in case you want the license info. There are lots of distros that don't mind spreading junk files on your system, so if you insist on it, those alternatives might be worth considering for your "serious work type projects."
*Mark Rosenstand: | On 3/9/06, Clare Johnstone <claregj@gmail.com> wrote: | > Whereas there may be a good reason to minimise the documentation provided with | > some utiities ( even though I disagree with that), when it comes to | > serious work type | > projects I think that policy should be given a serious rethink for | > every package, and | > in general, for the whole distro, It is crippling it. AND it is a lot | > of extra work to have | > to fix each Pkgfile to get the product in the form its authors intended. | > | > I have said this before, and will probably say it again. I just hope | > someone is listening. | | One of the principles of design in CRUX is to remove junk files. Files | that you'll only (if ever) read once are, IMO, junk. Since CRUX is | source based, you already have a local copy of the source in case you | want the license info. I recently installed some KDE programs, and I was a little bit annoyed when the help functions in the programs didn't work because the help files were missing. Of course, I can just remove the «rm helpfiles» line from the Pkgfile, but I don't believe this was the intention of removing junk files. I have also used other systems, where there often is an overfilled /usr/share/doc directory, or something like that. This dir often has manuals in PDF or some other format. These manuals can usually be retrieved from the Internet when needed. Info is also a format I really hate to deal with, and projecs providing info manuals, usually has it on the Internet as HTML files. I agree with Per that man pages should be kept, because they let you find useful information fast, and because they are standard on *nices. Files that programs use when they run, on the other hand, are not junk, but an unmanageable forest of manuals in different formats is. -- Robert Bauck Hamar Quidquid latine dictum sit, altum sonatur.
On Thursday 09 March 2006 15:00, Robert Bauck Hamar wrote:
*Mark Rosenstand: | One of the principles of design in CRUX is to remove junk files. | Files that you'll only (if ever) read once are, IMO, junk. Since | CRUX is source based, you already have a local copy of the source | in case you want the license info.
I recently installed some KDE programs, and I was a little bit annoyed when the help functions in the programs didn't work because the help files were missing. Of course, I can just remove the «rm helpfiles» line from the Pkgfile, but I don't believe this was the intention of removing junk files.
Me neither in this specific case. That's why I detailed my description of junk as "files you'll only (if ever) read once" - e.g. licenses, README's, etc. The KDE documentation is more of a lookup which is nicely integrated with the applications, but what's worse: not all is (to my knowledge) available online.
I have also used other systems, where there often is an overfilled /usr/share/doc directory, or something like that. This dir often has manuals in PDF or some other format. These manuals can usually be retrieved from the Internet when needed. Info is also a format I really hate to deal with, and projecs providing info manuals, usually has it on the Internet as HTML files. I agree with Per that man pages should be kept, because they let you find useful information fast, and because they are standard on *nices.
Files that programs use when they run, on the other hand, are not junk, but an unmanageable forest of manuals in different formats is.
If documentation is nicely integrated with the application, as it's the case with KDE, it isn't junk in my world either. Could we get a comment (and maybe even action) from the KDE maintainer/packager? :-)
On Thursday 09 March 2006 20:55, Mark Rosenstand wrote:
Could we get a comment (and maybe even action) from the KDE maintainer/packager? :-)
http://marc.theaimsgroup.com/?l=crux&m=103359513422098&w=2 At that time most people hanging around in #crux told me to remove it. I have never needed KDE's help system myself. However, maybe it's time to rethink the "3.4.3. Remove Junk Files" maxim - at least for files which are needed for proper program operation. I'm getting an error message if I try to open kmail's handbook. It's not exactly the same situation but somehow similar: http://marc.theaimsgroup.com/?l=crux&m=111576109526496&w=2 bye, danm -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A
El Thursday, 9 de March de 2006 10:00 am, Robert Bauck Hamar escribió:
I recently installed some KDE programs, and I was a little bit annoyed when the help functions in the programs didn't work because the help files were missing. Of course, I can just remove the «rm helpfiles» line from the Pkgfile, but I don't believe this was the intention of removing junk files.
I completely agree with you, in the particular case of KDE. Without the helpfiles you can't even install other languages. This means that if you want other languages, you have to rebuild kdelibs!
On Thursday 09 March 2006 3:07, Alan Mizrahi wrote:
I completely agree with you, in the particular case of KDE. Without the helpfiles you can't even install other languages.
This means that if you want other languages, you have to rebuild kdelibs!
I know exactly what you mean. :-) Honestly, I have to build kdelibs twice, every time I update CRUX's KDE packages: once for the public copy, and once for myself. On Thursday 09 March 2006 12:55, Mark Rosenstand wrote:
If documentation is nicely integrated with the application, as it's the case with KDE, it isn't junk in my world either. Could we get a comment (and maybe even action) from the KDE maintainer/packager? :-)
I've been considering how to breach to topic of the creation of /usr/share/doc for some time, and am actually kind of glad that it has become a community issue, and not just a personal inconvenience. Speaking of stripping documentation: am I the only one who has noticed that OpenOffice is not stripped of its documentation? Is this because the documentation is stored someplace "out of the way" (/usr/lib/openoffice/help)? To my knowledge, kde cannot simply be ./configur'ed to change /usr/share/doc to /usr/lib/kde3/doc, so it looks like a big "allow or disallow /usr/share/doc" decision. Though back to the topic of KDE-related documentation: Would only core KDE stuff be permitted to install documentation, or would all KDE software be able to? For example, does anyone need/want amaroK's documentation? KOffice's? Smb4k's? BasKet? I'm certainly for allowing core KDE stuff to install documentation. If the CLC likes the idea, I'll commit the changes. Cheers, Nick
On Friday 10 March 2006 11:16, Nick Steeves wrote:
On Thursday 09 March 2006 12:55, Mark Rosenstand wrote:
If documentation is nicely integrated with the application, as it's the case with KDE, it isn't junk in my world either. Could we get a comment (and maybe even action) from the KDE maintainer/packager? :-)
I've been considering how to breach to topic of the creation of /usr/share/doc for some time, and am actually kind of glad that it has become a community issue, and not just a personal inconvenience.
To my knowledge, kde cannot simply be ./configur'ed to change /usr/share/doc to /usr/lib/kde3/doc, so it looks like a big "allow or disallow /usr/share/doc" decision.
I think /usr/share/doc is the right place for it (at least according to the FHS which states "platform independant application data") - but the location isn't the issue; it's the junk people tend to put in there :-)
Would only core KDE stuff be permitted to install documentation, or would all KDE software be able to? For example, does anyone need/want amaroK's documentation? KOffice's? Smb4k's? BasKet?
I'd say all KDE applications because the "affects runtime" argument also count for them. Actually I think it's more important for them to have it since the docs for kde.org releases can be found on the net, but that's far from the case for all the third-party applications.
Mark Rosenstand wrote:
On Friday 10 March 2006 11:16, Nick Steeves wrote:
On Thursday 09 March 2006 12:55, Mark Rosenstand wrote:
If documentation is nicely integrated with the application, as it's the case with KDE, it isn't junk in my world either. Could we get a comment (and maybe even action) from the KDE maintainer/packager? :-)
I consider docs to be good but not to default to install test suites. I've been considering how to breach to topic of the creation of /usr/share/doc for some time, and am actually kind of glad that it has become a community issue, and not just a personal inconvenience.
To my knowledge, kde cannot simply be ./configur'ed to change /usr/share/doc to /usr/lib/kde3/doc, so it looks like a big "allow or disallow /usr/share/doc" decision.
Why can't KDE use man pages? why need a /usr/share/doc when we have man for manuals
and if there arn't any man formated pages, wouldn't there be a program to turn text or html docs into man pages?
I think /usr/share/doc is the right place for it (at least according to the FHS which states "platform independant application data") - but the location isn't the issue; it's the junk people tend to put in there :-)
Would only core KDE stuff be permitted to install documentation, or would all KDE software be able to? For example, does anyone need/want amaroK's documentation? KOffice's? Smb4k's? BasKet?
I'd say all KDE applications because the "affects runtime" argument also count for them. Actually I think it's more important for them to have it since the docs for kde.org releases can be found on the net, but that's far from the case for all the third-party applications.
On Thu, 09 Mar 2006 14:25:15 +0200, Mark Rosenstand wrote:
On 3/9/06, Clare Johnstone wrote:
One of the principles of design in CRUX is to remove junk files. Files that you'll only (if ever) read once are, IMO, junk. ...
I agree with you. However as soon as people are different, the different are points on what 'junks' are. While I hate annoying LICENSE's, README's, FAQ's etc, I also hate those who cut useful documentation. Somebody thinks that KDE documentation is useless, and this makes some trouble when I want to learn about some awesome feature. Maybe I'll read it once, but I would read it in place and fast enough. I think it's good to remove junks, but it's bad to prevent software from normal operation. -- Regards, [GRIM-UANIC] [GRIM-RIPE] Oleksiy V. Khilkevich National Technical University of Ukraine "Kyiv Polytechnic Institute" -- Please avoid sending me Word, Excel or PowerPoint attachments. Use plain text, HTML or PDF instead. http://www.gnu.org/philosophy/no-word-attachments.html
participants (9)
-
Alan Mizrahi -
Clare Johnstone -
Daniel Mueller -
Danny -
Mark Rosenstand -
Mark Rosenstand -
Nick Steeves -
Oleksiy V. Khilkevich -
Robert Bauck Hamar