[...]
Right, but typing xxx.html.gz will work! We can write a litte sed script
to change the links from xxx.html to xxx.html.gz inside the documents.
What do the popular http daemons do about this? I think a good solution
would be:
For every .html request that comes in (or perhaps
[EMAIL PROTECTED] writes:
[snip]
For every .html request that comes in (or perhaps for any request in
general), look for a file fitting the traditional spec.
If that fails, look for a .gz version of that file in the same directory.
If that fails, return the usual 404 error.
Sounds
On 25 Jun 1997, Marco Budde wrote:
Am 23.06.97 schrieb pdm # informatics.muni.cz ...
MZ - Limited possibilities of handling gzip files (typing xxx.html
MZ doesn't find xxx.html.gz) = problems with links (may be solvable by
Right, but typing xxx.html.gz will work! We can write a litte
Am 23.06.97 schrieb pdm # informatics.muni.cz ...
Moin Milan!
MZ - It's non-free.
That's a real problem.
MZ - It's big.
But not bigger than xemacs!
MZ - It can't run on text console.
But lynx can.
MZ - Limited possibilities of handling gzip files (typing xxx.html
MZ doesn't find
[EMAIL PROTECTED] (Rob Browning) wrote on 23.06.97 in [EMAIL PROTECTED]:
Ricardas Cepas [EMAIL PROTECTED] writes:
As of current documentation, you can search only current
.html file. This is not very usefull.
Lynx ( on non-gzipped docs) is much slower then info ( on
Am 26.06.97 schrieb branden # purdue.edu ...
Moin!
b For every .html request that comes in (or perhaps for any request in
b general), look for a file fitting the traditional spec.
b If that fails, look for a .gz version of that file in the same directory.
b If that fails, return the usual 404
Am 26.06.97 schrieb liw # iki.fi ...
Moin Lars!
LW Nothing, as far as I know. dwww, however, fixes thing correctly. That
But dwww is very slow (on my 486SL notebook).
LW doesn't help people who wish to browse documentation without using a
Right, for this people I've written an online help
ghughes == ghughes [EMAIL PROTECTED] writes:
ghughes True. However, it can't handle gzipped pages, and
ghughes hacking it to do so seems a) special case (because
Ermm... on my system it can. lynx 2.7-1 (self compiled).
netscape also handles it very well. I can't say about others
Rob == Rob Browning [EMAIL PROTECTED] writes:
Rob Ricardas Cepas [EMAIL PROTECTED] writes:
As of current documentation, you can search only current .html
file. This is not very usefull. Lynx ( on non-gzipped docs) is
much slower then info ( on gzipped).
Rob Oh, right I
[EMAIL PROTECTED] (Marco Budde) wrote on 21.06.97 in [EMAIL PROTECTED]:
But this requires a www server! Not a good idea for slow systems like my
notebook. And the result doesn't look great.
From: [EMAIL PROTECTED] (Kai Henningsen)
Isn't there a mini www server in Perl's web modules
Lynx can
Your're kidding ;-)? There're several really great HTML browsers like
netscape, lynx etc. And you should remember that for example KDE will use
I don't think he's kidding. Lynx is *awful* for searching (it doesn't
even have a keystroke for same pattern, next occurance...) Netscape,
well,
On Jun 22, Mark Eichin wrote
I don't think he's kidding. Lynx is *awful* for searching (it doesn't
even have a keystroke for same pattern, next occurance...)
Eh? 'n' seems to do a pretty good job. Seems like it searches just fine to
me :-)
Chris
--
On Jun 22, Chris Lawrence wrote
On Jun 22, Mark Eichin wrote
I don't think he's kidding. Lynx is *awful* for searching (it doesn't
even have a keystroke for same pattern, next occurance...)
Eh? 'n' seems to do a pretty good job. Seems like it searches just fine to
me :-)
As
On Jun 22, Bruce Perens wrote
Lynx can browse files directly, and can execute CGI scripts directly.
True. However, it can't handle gzipped pages, and hacking it to do so
seems a) special case (because chimera, w3, netscape and all the others
still don't) and b) outside of its domain of
MB == Marco Budde [EMAIL PROTECTED] writes:
MZ: I don't know any good browser for HTML, that's the main
MZ: problem of HTML documentation.
MB: Your're kidding ;-)? There're several really great HTML
MB: browsers like netscape, lynx etc.
No.
Problems with netscape:
- It's
Ricardas Cepas [EMAIL PROTECTED] writes:
As of current documentation, you can search only current
.html file. This is not very usefull.
Lynx ( on non-gzipped docs) is much slower then info ( on
gzipped).
Oh, right I forgot to add recursive to my previous comment about
ghughes == ghughes [EMAIL PROTECTED] writes:
ghughes [1 text/plain; us-ascii (7bit)] On Jun 22, Bruce Perens
ghughes wrote
Lynx can browse files directly, and can execute CGI scripts
directly.
ghughes True. However, it can't handle gzipped pages, and
ghughes hacking
[EMAIL PROTECTED] (Marco Budde) wrote on 21.06.97 in [EMAIL PROTECTED]:
But this requires a www server! Not a good idea for slow systems like my
notebook. And the result doesn't look great.
Isn't there a mini www server in Perl's web modules, about one or two
screend of Perl? (I don't
[ CC'ed to Christian for policy question, and to Manoj for VM example. ]
Marco Ask the users! The most people hate the info format and it's
Marco browsers. We should include the HTML documentation in the package.
But they get html via the dwww package! Which gives them _more_ documentation
Scott K. Ellis [EMAIL PROTECTED] writes:
Okay, show me how to search a HTML version of the bash info documentation
for a concept and I'll believe you.
Absolutely, anything without regex and incremental search is broken
and unacceptable for documentation purposes (IMO).
--
Rob
--
TO
Am 20.06.97 schrieb schwarz # monet.m.isar.de ...
Moin Christian!
CS Just unpack all .tar.gz files in the same directory and use the file
CS HOWTO-INDEX-3.html as index.html. It contains an overview over all
CS available HOWTOs and mini-HOWTOs and hyperlinks to them.
Oh no, that's not a good
Am 20.06.97 schrieb pdm # informatics.muni.cz ...
Moin Milan!
MZ There is one good info browser: GNU Emacs. On the other side I don't
MZ know any good browser for HTML, that's the main problem of HTML
MZ documentation.
Your're kidding ;-)? There're several really great HTML browsers like
Am 21.06.97 schrieb edd # rosebud.sps.queensu.ca ...
Moin Dirk!
DE But they get html via the dwww package! Which gives them _more_
DE documentation then there is in html only.
But this requires a www server! Not a good idea for slow systems like my
notebook. And the result doesn't look great.
Lars It was decided many moons ago that Debian would use HTML as its
Lars primary on-line documentation format. HTML should be the default.
Marco That's right. But a lot of important packages like doc-linux don't
Marco use HTML.
Well, the maintainer (that's me) prefers info as the
On Thu, 19 Jun 1997, Dirk Eddelbuettel wrote:
[snip]
However, Christian Schwarz asked me to do html as well. That will be some
work as HOWTO packages comes as tar.gz files with no surcompassing
index.html. I'll have to do some perl hacking. No promises for the June
release, maybe for July.
MB == Marco Budde [EMAIL PROTECTED] writes:
MB: The most beginners don't like info because there's no good
MB: browser. I would vote for texi2html because it look's much
MB: better than info2html and the user doesn't need a WWW server.
There is one good info browser: GNU Emacs. On
Am 16.06.97 schrieb sanvila # unex.es ...
Moin Santiago!
SVD The simplest solution is to ship html in a different package. This way
SVD the user will be able to choose to not install the html docs if he/she
SVD believes info2www is enough.
Ask the users! The most people hate the info format and
-BEGIN PGP SIGNED MESSAGE-
On 20 Jun 1997, Marco Budde wrote:
SVD The simplest solution is to ship html in a different package. This way
SVD the user will be able to choose to not install the html docs if he/she
SVD believes info2www is enough.
Ask the users! The most people hate
Am 16.06.97 schrieb liw # iki.fi ...
Moin Lars!
LW It was decided many moons ago that Debian would use HTML as its
LW primary on-line documentation format. HTML should be the default.
That's right. But a lot of important packages like doc-linux don't use
HTML.
LW is done with texi2html. For
-BEGIN PGP SIGNED MESSAGE-
Christian Schwarz [EMAIL PROTECTED] writes:
On 15 Jun 1997, Ardo van Rangelrooij wrote:
I have another policy issue which is related to topic 11 (see below).
The current layout of Info entries in the main Info menu (in the file
/usr/info/dir)
Santiago Vila Doncel [EMAIL PROTECTED] writes:
[snip]
The simplest solution is to ship html in a different package. This way
the user will be able to choose to not install the html docs if he/she
believes info2www is enough.
It might be nice if different types of duplicate documentation
On Mon, 16 Jun 1997, Erik B. Andersen wrote:
I cannot agree more. We should definatly add these fields to the
.deb package format! This will involve a bit of work, but will be
VERY worth it. No more licensing surprises, for instance.
I second that!
This would even make my proposed
On Mon, 16 Jun 1997, Santiago Vila Doncel wrote:
On Sun, 15 Jun 1997, Christian Schwarz wrote:
TOPIC 7: new definition of ``free software''
This is only about the main section.
In addition to that, I wonder why we are supporting this packages in the
`contrib' section:
* whose
-BEGIN PGP SIGNED MESSAGE-
Sorry, I didn't explain well. I said:
*---
I wonder why we are supporting this packages in the `contrib' section:
* whose copyright permission notices (or patent problems) allow only
On Jun 17, Santiago Vila Doncel wrote
Sorry, I didn't explain well. I said:
*---
I wonder why we are supporting this packages in the `contrib' section:
* whose copyright permission notices (or patent problems) allow
[EMAIL PROTECTED] (Fernando) wrote:
Author: name and email of main upstream author (copyright holder)
License: code describing license type
Original-Site: site/URL at which the package is originally stored
Yes.
We could even go further and specify the type of non-free license.
Common types are:
On Jun 17, Christian Schwarz wrote:
Original-Site: site/URL at which the package is originally stored
Ok. I think Original-Site is used in the .lsm entries. Wouldn't
something like Upstream-Site be better?
It is important that more than one Upstream-Site field is allowed.
Not for alternate
-BEGIN PGP SIGNED MESSAGE-
Hi,
I have another policy issue which is related to topic 11 (see below).
The current layout of Info entries in the main Info menu (in the file
/usr/info/dir) looks rather messy. I found the following descrepencies:
- not all packages are placed in an
On 15 Jun 1997, Rob Browning wrote:
[EMAIL PROTECTED] (Mark Baker) writes:
Would programs _have_ to use this library, or is implementing the same thing
in acceptable? The latter has problems in that it forces us to keep the same
method, but I don't want to see lots of #ifdef debian
On Sun, 15 Jun 1997, Jim Pick wrote:
All packages that provide HTML documentation should register these
documents to the menu system, too. Check out section section 4.1,
`Web
servers and applications' for details.
Is that as well as registering with dwww?
I'm
On Sun, 15 Jun 1997, Jim Pick wrote:
All packages that provide HTML documentation should register these
documents to the menu system, too. Check out section section 4.1,
`Web
servers and applications' for details.
Is that as well as registering with
Christian Schwarz [EMAIL PROTECTED] writes:
This really is an _excellent_ idea! So, we just need a volunteer to
implement and maintain this upstream library. (The packaging for Debian
should not be a problem.)
Ideally we could provide C, perl, python, etc versions of the code.
--
Rob
--
On 16 Jun 1997, Rob Browning wrote:
Christian Schwarz [EMAIL PROTECTED] writes:
This really is an _excellent_ idea! So, we just need a volunteer to
implement and maintain this upstream library. (The packaging for Debian
should not be a problem.)
Ideally we could provide C, perl,
On Mon, 16 Jun 1997, joost witteveen wrote:
[snip]
I'm somehow confused now. Is registering to dwww any different from the
menu system? Joost, perhaps you can give use some hints here (I think
Jim is offline now).
It used to be the same, and that's why I also asked Jim about that.
But
On 15 Jun 1997, Ardo van Rangelrooij wrote:
I have another policy issue which is related to topic 11 (see below).
The current layout of Info entries in the main Info menu (in the file
/usr/info/dir) looks rather messy. I found the following descrepencies:
- not all packages are placed
TOPIC 8: packages have to specify their source urls
---
STATUS: DISCUSSION
In addition to what you propose below, I think that dpkg -I should be
concerned with some of that info. Specifically, three important fields are
missing:
Author:
-BEGIN PGP SIGNED MESSAGE-
On Sun, 15 Jun 1997, Christian Schwarz wrote:
TOPIC 7: new definition of ``free software''
This is only about the main section.
In addition to that, I wonder why we are supporting this packages in the
`contrib' section:
* whose copyright permission
-BEGIN PGP SIGNED MESSAGE-
On Sun, 15 Jun 1997, Christian Schwarz wrote:
TOPIC 11: policy about including documentation
The current policy concerning docs is:
- HTML is the preferred format
- if the package includes docs than can be converted into HTML,
the
In article [EMAIL PROTECTED],
Christian Schwarz [EMAIL PROTECTED] writes:
The current structure (of packages installed on my system) is:
Miscellaneous
Development
Document Preparation
Information
Emacs
Programming
teTeX
Graphics
I cannot agree more. We should definatly add these fields to the
.deb package format! This will involve a bit of work, but will be
VERY worth it. No more licensing surprises, for instance.
-Erik
--
Erik B. Andersen Web:http://www.inconnect.com/~andersen/
email:
Note, that this is the first message of this type. My apologizes if
the mail is too large. I was thinking about creating an extra mailing
list of policy related discussions, or about setting up a HyperNews
server to discuss these topics. However, I think this is (better:
should) be important for
In article [EMAIL PROTECTED],
Christian Schwarz [EMAIL PROTECTED] writes:
All packages that provide HTML documentation should register these
documents to the menu system, too. Check out section section 4.1, `Web
servers and applications' for details.
Is that as well as
[EMAIL PROTECTED] (Mark Baker) writes:
Would programs _have_ to use this library, or is implementing the same thing
in acceptable? The latter has problems in that it forces us to keep the same
method, but I don't want to see lots of #ifdef debian appearing in the
original source; apart from
All packages that provide HTML documentation should register these
documents to the menu system, too. Check out section section 4.1, `Web
servers and applications' for details.
Is that as well as registering with dwww?
I'm changing the way documents register themselves
In article [EMAIL PROTECTED],
Mark Baker [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED],
Christian Schwarz [EMAIL PROTECTED] writes:
Currently some packages do one and some the other.
2. Build a shared library ``libdebian'', that contains
functions to lock,
Miquel van Smoorenburg wrote:
SystemV has standard library functions for this. Qpopper can use them if
compiled under Solaris. So for qpopper, I just created those functions myself.
It might be a good idea to put them in a small (not shared) library, so
other programs can use them. And the
56 matches
Mail list logo
