Further developments w.r.t. KDevelop documentation nightmare.

[Bjoern Krombholz]

On Thu, 10 Feb 2000, Paul Derbyshire wrote:
> I'm not so sure now. I tried using symlinks to make the C/C++ reference
> work at least and it won't. Suspicious, I investigated and sure enough,
> there is a skeleton but no content. 

Better you describe what you tried, so someone could help you.
By the way there were a lot of postings in the last 2 weeks depending on
this - there should be anything working you?!

> The C/C++ reference was downloaded directly from the kdevelop team's
> own FTP site, so there are no middlemen and hence cannot have been any
> errors by middlemen. This empty documentation package was distributed
> directly by the kdevelop team. I think that might be reasonably
> considered a dumbass error for which an apology is owed.

The package works for a lot of people. C/C++ reference isn´t created by
the "KDevelopers" but they were so kind to build a RPM that may work. In
my opinion there is no way to build complex packs that will install
correctly on every distribution/system.

[...]
> * The C/C++ reference in a package (rpm preferred, otherwise tarball)
> that
>   actually has content and not just a skeleton directory structure,
> and * The Kdevelop user guide in a similar form, since it presumably
> doesn't come
>   with the sources. Same requirement that the content actually be there.

Maybe there´s something wrong with _your_ system?!

And build your own RPM´s from tarballs when you can´t stay without.

> No more documentation vaporware will be tolerated here, coming from anyone!
> 
> Do NOT tell me to go get the documentation packages, source packages, or
> whatever from a) your FTP site or b) rpmfind.net, as clearly I can trust
> neither. 

You don´t have to - and even don´t have to download anything ;)

> [...] I'm certainly not
> downloading a package, rebooting quickly to Linux, installing it, finding
> that that one doesn't work, rebooting very slowly to Windows, laboriously
> downloading another alternative package, rebooting... 

Download with Linux!!
 
> Tools should run and work perfectly out of the box; their sources should
> configure and build out of the box. Even development tools. 

just do:
download tarball
unpack tarball
./configure --prefix="$KDEDIR"
make install

That´s it!
And you´ll have user manual installed, too!

> [...] And if you want KDE to grow a large app
> base you want your kdevelop user base to expand.

Actually it grows and grows and ...

[...]
> I don't expect a major new 1.1.x release, just a maintenance pack that
> addresses these issues/bugs/warts.
> 
> * Ship a source package that includes ALL the docs, except the kde-libs and Qt
>   docs, which are generated anyways rather than prepackaged.

Hopefully there will be such a package called KDK like for KDevelop 1.0.

> * Make sure the damned thing works! A serious fault like a non-ASCII character
>   in a source file should certainly get discovered by even the most
> preliminary
>   testing. [...]

That´s why it´s called beta.

> * Make sure the configure script creates a symlink /usr/doc/kde/HTML/default
>   pointing to /usr/doc/kde/HTML/<the two letter code for the system locale>.

Don´t do so!! A lot of things don´t work with this.
default links to en after installing KDE and it should stay!
Set your language in Control Center instead.

> * No /opt/kde nonsense. make install puts all the binaries in $KDEDIR/bin
>   and the docs in /usr/doc/kde/HTML, while the shared stuff, such as icons,
>   goes in $KDEDIR/share. Respect the $KDEDIR.

This is _your_ opinion - I wouldn´t like to have kde docs in /usr, that
makes it easier to put the whole KDE stuff on another partition f.e. ...

> * For users of Debian and other distributions, issue a tarball, not a RPM;
>   include an instruction file on the Web site and "next to" the tarball for
>   where to untar it. 

Why not building debian/UnixWare/Stampede... packages?
Packages for everybody! ;)

If you want to work with KDevelop you will need a compiler, so it´s
installed, so stop packaging and compile by your own, so you will even
learn something about your system... :-) That´s my opinion and I am no
hardcore developer, indeed!

> * Leave instructions for those that would redistribute it in RPMs, .debs,
>   .pkgs, etc. to make damned sure they don't omit anything, mix in files from
>   older versions, fail to respect $KDEDIR on install, or otherwise screw it
> up.
>   Obviously, packagers can't in general be trusted to DTRT on their own
> without
>   expert guidance from the authors that made whatever it is they are
> packaging.
 
Where is the right place for package to install?
But you are right: trust nobody a foriori yourself! ;) 

In general - you may have your opinion and good ideas but you should
follow some rules in communication with other people and offering critics.
You do not need to abuse somebody or his work in such a
condescend way, otherwise the only thing you´ll get back (and in my
opinion earn) is some flame against you.

Bjoern

-- 
Sign the Linux Driver Petition at http://www.libranet.com/petition.html