Re: [devel-ref] author/homepage in description
On Mon, Dec 09, 2002 at 09:50:22PM -0500, Joey Hess wrote: Denis Barbier wrote: For translators having a development URL is also useful, because they can then send up to date translations; it was said that it is then available from package homepage, but some packages have no homepage and have a public CVS repository. I'm not sure what a development URL is. You cannot really give an url directly to a cvs repository and surely it'd not be world readable anyway. Right, I was thinking of a cvsweb interface. It would also be very helpful to know when packages have upstream translation teams, e.g. in GNU, GNOME or KDE projects, so that Debian translators do not interfere with their work. IMO a Project field is enough, its value being either some known values or an URL. Last point, it is frustrating to work on translations which are never incorporated. For instance if you do not want to bother with the FSF disclaimer, you might want to know whether an author mandates it or not. I guess I don't see any of these things being worth bloating Packages files with. You don't need them at install time; the info is probably not even needed in binary packages. Agree. Again my only goal is to have more accurate links at www.d.o/intl/l10n/ I could maintain a database with the needed informations for each package, but it would be a lot simpler if developers provide them in a standardized way. If a translator needs the source package anyway to do translation work, such info could just be present in there. If you want to spec out a file that goes in source packages for this kind of structured data, fine. uscan files are a good example of something similar. Ok, will look at them. Please ignore my initial request, I no longer need extra fields in debian/control and will think of a new file in source packages. Thanks. Denis
Bug#172022: FWD: Re: description writing guide
On Mon, Dec 09, 2002 at 06:27:55PM -0800, Osamu Aoki wrote: ... +sect1 id=synopsisheadingThe single line synopsis/heading p The single line synopsis should be kept brief - certainly The line that follows is: under 80 characters. This is a sufficient restriction IMO. -- 2. That which causes joy or happiness.
Re: should XML/SGML documentation ship with sources
On Sun, Dec 08, 2002 at 04:32:10PM -0600, Adam DiCarlo wrote: Is it a good practice for SGML or XML documentation to ship with source? My preference would be to include the source plus both text and html renderings. This provides both convieniently pre-formated output for on-line viewing plus the ability to generate hard-copy for the user's specific output device requirements (paper and printer type). --bod
Re: should XML/SGML documentation ship with sources
On Tue, Dec 10, 2002 at 11:23:41PM +1100, Brendan O'Dea wrote: Is it a good practice for SGML or XML documentation to ship with source? My preference would be to include the source plus both text and html renderings. This provides both convieniently pre-formated output for on-line viewing plus the ability to generate hard-copy for the user's specific output device requirements (paper and printer type). The problem is that this generation is not guaranteed to work, due to various intricate details of document build systems. -- 2. That which causes joy or happiness.
Bug#172436: debian-policy: [PROPOSAL] web browser url viewing
Joey Hess [EMAIL PROTECTED] writes: Package: debian-policy Version: 3.5.8.0 Severity: normal As discussed earlier on this list, and now implemented by lots of stuff in Debian[2] and with only a few to go[3], I'm proposing that the following be added to policy around section 12.4: Web browsers Some programs have the ability to launch a web browser to display an URL. Since there are lots of different web browsers available in the Debian distribution, the system administrator and each user should have the possibility to choose a preferred web browser. In addition, programs should choose a good default web browser if none is selected by the user or system administrator. Thus, every program that launches a web browser with an URL must use the BROWSER environment variable to determine what browser the user wishes to use. The value of BROWSER may consist of a colon-separated series of browser command parts. These should be tried in order until one succeeds. Each command part may optionally contain the string %s; if it does, the URL to be viewed is substituted there. If a command part does not contain %s, the browser is to be launched as if the URL had been supplied as its first argument. The string %% must be substituted as a single % footnote This browser variable was proposed by Eric Raymond at http://www.tuxedo.org/~esr/BROWSER/ /footnote If the BROWSER environment variable is not set, the program should use /usr/bin/x-www-browser if there is an available X Window System DISPLAY, and /usr/bin/www-browser if not. These two files are managed through the dpkg alternatives mechanism. Thus every package providing a general-purpose web browser must call the update-alternatives program to register the appopriate one of these alternatives. If it is very hard to adapt a program to make use of the BROWSER variable, that program may be configured to use /usr/bin/sensible-www-browser instead. This is a program provided by the Debian base system that checks the BROWSER environment variable, and falls back to /usr/bin/x-www-browser or /usr/bin/www-browser if it is not set. Seconded. Lukas -- This is not a signature
Re: [devel-ref] author/homepage in description
On Tue, Dec 10, 2002 at 12:34:17AM +0100, Denis Barbier wrote: On Mon, Dec 09, 2002 at 11:28:46PM +, Julian Gilbey wrote: [...] I doubt that translators will need to extract such information in an automatic manner. If these informations were available, http://www.debian.org/intl/l10n/po/lang/ could point to CVS files instead of released ones. And as explained in a previous post, Debian translators could also skip GNU, GNOME and KDE packages (amongst others) which have their own l10n teams. At present, I am still quite sceptical that there are that many packages/sites which could be automated in this way to point to appropriate CVS files. What would probably make sense is for there to be an organised or even automated way for the debian l10n links to be set up for such packages without there needing to be data added to the control file. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: [devel-ref] author/homepage in description
Josip Rodin [EMAIL PROTECTED] writes: On Mon, Dec 09, 2002 at 01:17:28PM -0600, Adam DiCarlo wrote: The point was validly raised in a previous thread that using these means changing packages twice in the event that dpkg is eventually changed. That I don't follow. Scenario: we start using XK-foo now, then wait for it to become common practice, dpkg gets changed to support foo, all those packages that have XK-foo need another change to s/XK-//. It's better to register a new field now, and start using that. That way we avoid extra work later. Fine, once the field is added, I'll use it. Until then, I think it's best to just use the description field. That way it's visible to users. Using the XK-Homepage field or whatever would be quite invisible. As for the extra work, it doesn't matter. -- ...Adam Di Carlo..[EMAIL PROTECTED]...URL:http://www.onshored.com/
Re: [devel-ref] author/homepage in description
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 10 December 2002 10:57, Denis Barbier wrote: [Initial request was to include author and/or homepage for package in the control file and as a result in the Packages file (IIRC)] Please ignore my initial request, I no longer need extra fields in debian/control and will think of a new file in source packages. Thanks. Well, from a users point of view, I would (and do) really appreciate homepage links in the description of packages. This serves two purposes for me: 1. Have a source for additional information when I am in doubt wether this package should be installed. 2. Having the ability to check wether the package is uptodate in relation to the upstream package. While I understand that there are thousands of packages (hmm, dpkg -l only shows 1080 on my stable system, but there must be more than that) and that adding 40 bytes of URL data to each means multiple kilobytes (possibly more than 200kBytes) of additional data in the Packages file(s), it _does_ provide additional value to the user. And after all, the Packages file is primarily for the user (though this is through tools like apt/dpkg/dselect/aptitude). Also, the packages.d.o site could convert these URLs to links when displaying the package in question. The use of this is more obvious than in the Packages file itself I think. Still, it is generated from the same source. Regards, Sven Müller - - IT - NetworkInfrastructure - - -- * Heinrich Berndes Haushaltstechnik GmbH Co KG * Wiebelsheidestrasse 55, 59757 Arnsberg, Germany * Phone: +49 2932 475-282 / FAX: -325 * http://www.berndes.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE99gqlss2fOBI6SZ0RAn9RAJ447ue/rCLNpk0+bAXU5W2uPHTIrwCffT4G 18Pt5Z/dp2CczsaQB1zMx6g= =nrbT -END PGP SIGNATURE-
Re: [devel-ref] author/homepage in description
On Tue, Dec 10, 2002 at 09:03:54AM -0600, Adam DiCarlo wrote: As for the extra work, it doesn't matter. It's not nice to screw around with other people's time like that. -- 2. That which causes joy or happiness.
Re: [devel-ref] author/homepage in description
Josip Rodin [EMAIL PROTECTED] writes: On Tue, Dec 10, 2002 at 09:03:54AM -0600, Adam DiCarlo wrote: As for the extra work, it doesn't matter. It's not nice to screw around with other people's time like that. I was under the guess that given the qty of dpkg bugs, it might take 6+ months, so a best practice stop-gap measure was appropriate (using the description field). It's completely voluntary for developers to use the stop-gap. So tell me, how am I screwing around with other people's time ? If you really think I should wait, I'll make sure a bug is filed against dpkg for Homepage field and then wait however long it takes for that to happen. -- ...Adam Di Carlo..[EMAIL PROTECTED]...URL:http://www.onshored.com/
Re: [devel-ref] author/homepage in description
On Tue, Dec 10, 2002 at 10:49:14AM -0600, Adam DiCarlo wrote: As for the extra work, it doesn't matter. It's not nice to screw around with other people's time like that. I was under the guess that given the qty of dpkg bugs, it might take 6+ months, so a best practice stop-gap measure was appropriate (using the description field). It's completely voluntary for developers to use the stop-gap. So tell me, how am I screwing around with other people's time ? It would have been exactly that if you chose to use XB-Upstream... the Description field is a bit better since you wouldn't be introducing a whole new thing (it already works, has worked for ages), but we will still have to convert from that to the proper field eventually. If you really think I should wait, I'll make sure a bug is filed against dpkg for Homepage field and then wait however long it takes for that to happen. I think there's one filed already. -- 2. That which causes joy or happiness.
Re: [devel-ref] author/homepage in description
On Tue, Dec 10, 2002 at 04:49:38PM +0100, Josip Rodin wrote: On Tue, Dec 10, 2002 at 09:03:54AM -0600, Adam DiCarlo wrote: As for the extra work, it doesn't matter. It's not nice to screw around with other people's time like that. But no one is *required* to do anything. (Yet, if ever.) This is a best-practices suggestion that only applies to packages which *have* a meaningful homepage. So, we have a suggestion for what we should do now and what we should do if/when dpgk changes, and anyone who doesn't want to waste their time can wait until dpkg changes. If this were going in policy (you [should/must] have a homepage link in your control file at point X if a site exists that can reasonably be described as a home page for the package), then I would definitely object. (Would create bugs for existing packages, for one thing.) But this isn't for policy, this is for dev-ref. If I have any remaining reservations about this proposal, it's that homepage is not (yet) an English word, IMO. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Bug#160827: syntax of the maintainer name in the Maintainer: field
On Sat, Dec 07, 2002 at 05:33:10PM -0500, Clint Adams wrote: True. It could get away with tossing everything outside angulars or inside brackets, though. The address can be mandated to stay 7bit for now. At any rate, people shouldn't be putting raw Latin1 in these fields. Amen. 7-bit ASCII only. -- G. Branden Robinson| Psychology is really biology. Debian GNU/Linux | Biology is really chemistry. [EMAIL PROTECTED] | Chemistry is really physics. http://people.debian.org/~branden/ | Physics is really math. pgp5xzuORE2nt.pgp Description: PGP signature
Re: [devel-ref] author/homepage in description
[EMAIL PROTECTED] (Denis Barbier) writes: Putting it in a README file won't help, it can't be automatically extracted. The problem is that debian/control is the only file with a parsable format, maybe such infos could be added to another file, say debian/infos, in a standardized manner. Joey Hess [EMAIL PROTECTED] writes: Well we already have the links in the copyright files now, so if they're going to be wrong half the time that must already be a problem. I think the link in the copyright file to the upstream sources should be in a standardized, parsable format. Likewise the author name. That way lintian could check for them. The last time I checked, 5 or 10 percent of our packages lacked any link to the upstream sources. Then, it would make sense to add a link to the project home page in the same place. That would not impact the Packages files. - Jim Van Zandt
Re: [devel-ref] author/homepage in description
James R. Van Zandt wrote: I think the link in the copyright file to the upstream sources should be in a standardized, parsable format. Likewise the author name. That way lintian could check for them. The last time I checked, 5 or 10 percent of our packages lacked any link to the upstream sources. Then, it would make sense to add a link to the project home page in the same place. That would not impact the Packages files. If you want a parseable link to the upstream source, use uscan files. Of course maybe 10% of all packages have them, but they're perfect for the job (and anyone who doesn't have one should add one). This is rather different than homepage links though. -- see shy jo pgpdYMPpOAMhp.pgp Description: PGP signature
