Re: DEP-5: general file syntax
Le Sat, Aug 21, 2010 at 09:09:28PM +1200, Lars Wirzenius a écrit : +There are four kinds values for fields. Each field specifies which +kind is allowed. +i +* Single-line values. +* White space separated lists. +* Line based lists. +* Free-form text formatted like package long descriptions. Hi Lars, I have mixed feelings about adding a extra level of complexity and introduce a syntax for lists. I think that apart from the Files field, the DEP could use mostly free-form values in the fields. In particular for the Copyright field, I am of the opinion that it should be free form and verbatim, preserving the newlines as they are in debian/copyright. One minor problem is that Policy §5.1 specifies that if a field value may not be wrapped, then this field is a single line of white space separated data, and indeed there is no field in Policy's chapter 5 that is purely free-form while preserving newlines characters. I have opened #593909 to disambiguate this. I also feel a contradiction to call ‘free-form’ some text that is formatted according to some markup rules, even if they are simple. I propose to replace instances like: Free-form text formatted like package long descriptions by: Formatted text like package long descriptions Here are additional comments between quotations of your patch. +`Copyright` can list many copyright statements, one per line. For fine-grained descriptions, I would rather recommend to write a SPDX file in cooperation with Upstream, and use it to generate a DEP-5 template. * **`Upstream-Name`** * Optional * Single occurrence + * Value: single line * Syntax: Single line (in most cases a single word), containing the name upstream uses for the software. * **`Upstream-Contact`** * Optional * Single occurrence + * Value: line based list * Syntax: Line(s) containing the preferred address(es) to reach the upstream project. May be free-form text, but by convention will usually be written as a list of RFC2822 addresses or URIs. The syntax of the Upstream-Contact field does not reflect the use intended by the Perl packaging team, which is to match a Debian package with a CPAN maintainer. The CPAN maintainer's email address not necessarly the preferred address to reach the upstream authors (for instance, a mailing list). Since this thread is not about the Upstream-* fields, let's not go too much in the details, except that in my opinion, ‘line based list’ is not the most appropriate format for the Upstream-Contact field's value. Another potential problem for both fields is that a Debian source package can be composed by multiple unrelated upstream works. All in all, I would recommend to make these fields free-form. Packaging teams that would like to use a more specialised syntax can add their own local policies on top of the DEP. @@ -99,13 +132,15 @@ * **`Source`** * Optional * Single occurrence + * Value: single line * Syntax: One or more URIs, one per line, indicating the primary point of distribution of the software. Since the syntax allows multiple URIs, and since the URIs may be long, I think that allowing newlines in the field will make it more readable. for instance by making it free-form (not formatted, see below). * **`License`** * Licensing terms for the files listed in **`Files`** field for this section * Required + * Value: free-form text, with special first line * Syntax: * First line: an abbreviated name for the license (see *Short names* section for a list of standard abbreviations). If empty, it is If the extended description finally requires double space for verbatim display, then how abould calling the ‘special first line’ synopsis, to be closer to the vocabulary used in the specification of the Description field ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100822071229.gb32...@merveille.plessy.net
Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’
On Sat, Aug 14, 2010 at 12:30:06PM +0900, Charles Plessy wrote: I propose to rename the ‘Maintainer’ field ‘Contact’, Please don't. Contact would be often misinterpreted as support or hotline: Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100822085553.gb25...@torres.zugschlus.de
FW: Request for application
Greetings I am Boumediene Bendermel, from Algeria, i am 33 years old, single, my job is a farmer i work in agriculture since 5 years of experience. I want to participate working there. Awaiting for your answer, accept my best compliments. Boumediene
UPDATE DEBIAN VER 2.1 ......AND MORE
HI . if this mesage is send to you by mistake please forward it to whom it may concern I am sorry to say that yours websites look like all LINUX TOO MUCH WORDS AND SCUM ABOUT NOTHING 1ST PROBLEM / I bought some years ago version 2.1 Alas ! my hope of freedom from from MICROSOFT dictatorship (*) soon evaporated In others words I gave up after ...a couple of mishaps and others UNLUCKY ATTEMPTS to contact your services I AM LOOKING NOW FOR A COME BACK BECAUSE WITH ADVANCING YEARS I AM REALLY FED UP WITH WINDOWS BECAUSE AFTER ALL THESE YEARS THE YOUTH WHO CONSTITUTE THE / KERNEL / LINUX SEAM MORE MATURE . I HOPE I AM NOT WRONG AGAIN ALAS / 2 / VERSION 2.1 IS NO LONGER BOOTABLE SHOULD I HANG MYSELF OR WHAT ? *\ --2 PROBLEM TWO WHEN SHALL WE SEE AT LAST A VERSION OF LINUX ACCESSIBLE TO THE LAYMAN WHICH COULD COMPETE WITH WINDOWS I HAVE STILL THAT DREAM =- (*) see twitter and www.chaterton.wordpress.com HOPE THIS MESSAGE DID NOT UPSET YOU MY CRITICISM COME FROM AN EXCESS LOVE FOR LINUX WHICH IN TURN IS DERIVED FROM EXCESS OF HATRED FOR MICROSOFT AND ALL FORMS OF DICTATORSHIP COME YOU CANNOT DISAGREE WITH THIS francais problem 1 Comment obtenir update de DEBIQN VER 2.1 PROBLEM 2 : PLUS GENERAL QUAND LES GAMINS QUI TRAVAILLENT POUR LINUX VONT ENFIN GRANDIR REUNIR TOUT CE MONDE AUTOUR DE TABLE ET PRODUIRE ENFIN UNE VERSION . DEBIAN OU AUTRE LINUX ACCESSIBLE A TOUS ... CAPABLE DE RIVALISER AVEC WINDOWS 0-- desole si le message est trop long IL FALLAIT QUE CES CHOSES SOIENT DITES PRIERE TRANSMETTRE SI NON CONCERNES
Re: UPDATE DEBIAN VER 2.1 ......AND MORE
Dne, 22. 08. 2010 20:28:45 je loualich andre napisal(a): 1ST PROBLEM / I bought some years ago version 2.1 Hmmm ... I doubt you'll be able to sell it now. Perhaps to a museum? ALAS / 2 / VERSION 2.1 IS NO LONGER BOOTABLE Due to the y2k bug, no doubt ... WHEN SHALL WE SEE AT LAST A VERSION OF LINUX ACCESSIBLE TO THE LAYMAN WHICH COULD COMPETE WITH WINDOWS I HAVE STILL THAT DREAM If you want a laid-back out-of-box experience, you should try a recent Ubuntu Live CD. -- Regards, Klistvud Certifiable Loonix User #481801 http://bufferoverflow.tiddlyspot.com Please reply to the list, not to me. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282505030.1314...@compax
Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’
On Sat, Aug 21, 2010 at 08:17:22PM +1200, Lars Wirzenius wrote: (Machiavelli was my pupil. All that he wrote in his little booklet he learned from the masterly way I direct Debian discussions.) +1 ...what I mean is: I acknowledge your power and let this point rest :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: UPDATE DEBIAN VER 2.1 ......AND MORE
On Sun, Aug 22, 2010 at 06:28:45PM +, loualich andre wrote: HI . if this mesage is send to you by mistake please forward it to whom it may concern I am sorry to say that yours websites look like all LINUX TOO MUCH WORDS AND SCUM ABOUT NOTHING 1ST PROBLEM / I bought some years ago version 2.1 Alas ! my hope of freedom from from MICROSOFT dictatorship (*) soon evaporated ALAS / 2 / VERSION 2.1 IS NO LONGER BOOTABLE Thank you for your interest in Debian. Version 2.1 of Debian has not been supported for almost ten years; it is not surprising that it's not bootable for you on modern hardware. If you are trying to install Debian, it is recommended that you use the most recent release, Debian 5.0. Information on installing Debian can be found here: http://www.debian.org/distrib/ This information is linked from the sidebar of the debian.org homepage under Getting Debian (« Obtenir Debian » à l'edition française). If you need further assistance with your Debian installation, it is recommended that you contact the debian-user mailing list at debian-u...@lists.debian.org, or one of the language-specific user support lists shown at http://lists.debian.org/users.html, such as debian-user-fre...@lists.debian.org. WHEN SHALL WE SEE AT LAST A VERSION OF LINUX ACCESSIBLE TO THE LAYMAN WHICH COULD COMPETE WITH WINDOWS I HAVE STILL THAT DREAM There are a number of Linux distributions that have as their focus accessibility to the layman. One of these, Ubuntu, is derived from Debian; you can learn more about this effort at www.ubuntu.com. Accessibility to non-experts is not the primary focus of the Debian project, but it is nevertheless important to us. If you have specific feedback about problems you have encountered running or installing Debian, you are always welcome to file a bug report in our Bug Tracking System. Information about using this system can be found here: http://www.debian.org/Bugs/ Please only use this to report specific concerns with the software that our developers can address. If you have doubts about whether something you've encountered is a bug, or which part of the system the bug is in, feel free to discuss the issue on the user mailing list first. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: DEP-5: general file syntax
On la, 2010-08-21 at 22:30 -0700, Manoj Srivastava wrote: Can't we just fold long copyright header fields similarly? The issue is that one Copyright field (or header) will contain many copyright statements, and if we want to automatically parse those, we need a way to see where a new one starts. However, since there seems to be no current plans to parse copyright statements out of the Copyright field, I think we can forget this issue, at least for now, and leave it for later generations to solve, if they start caring. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282514128.12989.386.ca...@havelock
Re: DEP-5: general file syntax
On su, 2010-08-22 at 16:12 +0900, Charles Plessy wrote: I also feel a contradiction to call ‘free-form’ some text that is formatted according to some markup rules, even if they are simple. I propose to replace instances like: Free-form text formatted like package long descriptions by: Formatted text like package long descriptions ACK, done. All in all, I would recommend to make these fields free-form. Packaging teams that would like to use a more specialised syntax can add their own local policies on top of the DEP. I disagree with this: I think a line-based list is perfectly fine for Upstream-Contact. Does anyone else have an opinion? @@ -99,13 +132,15 @@ * **`Source`** * Optional * Single occurrence + * Value: single line * Syntax: One or more URIs, one per line, indicating the primary point of distribution of the software. Since the syntax allows multiple URIs, and since the URIs may be long, I think that allowing newlines in the field will make it more readable. for instance by making it free-form (not formatted, see below). Actually, I think I made a mistake: I think Source should be a line-based list. This will make it easier for parsers to extract the URIs. Splitting a URI to two physical lines seems to me a bad idea, and messes up URI parsing in too many contexts. (The real fix is to get upstream to not have excessively long URIs, but that's hard to fix.) If the extended description finally requires double space for verbatim display, then how abould calling the ‘special first line’ synopsis, to be closer to the vocabulary used in the specification of the Description field ? Could some English experts weigh in whether the word synopsis is a good way to describe the list of license short names? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282514846.12989.396.ca...@havelock
Re: DEP-5: general file syntax
I've attached the current diff for the general file syntax changes. === modified file 'dep5.mdwn' --- dep5.mdwn 2010-08-21 09:05:12 + +++ dep5.mdwn 2010-08-22 22:08:51 + @@ -76,7 +76,7 @@ * Single-line values. * White space separated lists. * Line based lists. -* Free-form text formatted like package long descriptions. +* Text formatted like package long descriptions. A single-line value means that the whole value of a field must fit on a single line. For example, the `Format` field has a single line value @@ -90,7 +90,7 @@ Another kind of list value has one value per line. For example, `Copyright` can list many copyright statements, one per line. -Free-form text is formatted the same as the long description in +Formatted text fields use the same rules as the long description in a package's `Description` field, possibly also using the first field in a special way, like `Description` uses it for the short description. @@ -132,14 +132,14 @@ * **`Source`** * Optional * Single occurrence - * Value: single line - * Syntax: One or more URIs, one per line, indicating the primary - point of distribution of the software. + * Value: line based list + * Syntax: One or more URIs, indicating the primary + points of distribution of the software. * **`Disclaimer`** * Optional * Single occurrence - * Value: free-form text, no special first line + * Value: formatted text, no special first line * Syntax: On Debian systems, this field can be used in the case of non-free and contrib packages (see [Policy 12.5]( @@ -183,7 +183,7 @@ * **`License`** * Licensing terms for the files listed in **`Files`** field for this section * Required - * Value: free-form text, with special first line + * Value: formatted text, with special first line * Syntax: * First line: an abbreviated name for the license (see *Short names* section for a list of standard abbreviations). If empty, it is
Re: DEP-5: general file syntax
Lars Wirzenius l...@liw.fi writes: On su, 2010-08-22 at 16:12 +0900, Charles Plessy wrote: If the extended description finally requires double space for verbatim display, then how abould calling the ‘special first line’ synopsis, to be closer to the vocabulary used in the specification of the Description field ? Could some English experts weigh in whether the word synopsis is a good way to describe the list of license short names? It's... okay. It's a little strange, but I don't think it would be confusing since it is a summary of the license text in a machine-readable format, in essence. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxsei8v1@windlord.stanford.edu
Re: DEP-5: general file syntax
On su, 2010-08-22 at 15:24 -0700, Russ Allbery wrote: It's... okay. It's a little strange, but I don't think it would be confusing since it is a summary of the license text in a machine-readable format, in essence. ACK, you and Ben have assured me that it is acceptable, and I've changed the spec draft. Latest diff attached. === modified file 'dep5.mdwn' --- dep5.mdwn 2010-08-17 20:47:26 + +++ dep5.mdwn 2010-08-23 02:47:59 + @@ -3,7 +3,7 @@ Title: Machine-readable debian/copyright DEP: 5 State: DRAFT - Date: 2010-08-18 + Date: 2010-08-23 Drivers: Steve Langasek vor...@debian.org, Lars Wirzenius l...@liw.fi URL: http://dep.debian.net/deps/dep5 @@ -70,6 +70,36 @@ http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-controlsyntax for details. +There are four kinds values for fields. Each field specifies which +kind is allowed. + +* Single-line values. +* White space separated lists. +* Line based lists. +* Text formatted like package long descriptions. + +A single-line value means that the whole value of a field must fit on +a single line. For example, the `Format` field has a single line value +specifying the version of the machine-readable format that is used. + +A white space separated list means that the field value may be on one +line or many, but values in the list are separated by one or more +white space characters (including space, TAB, and newline). For +example, the `Files` field has a list of filename patterns. + +Another kind of list value has one value per line. For example, +`Copyright` can list many copyright statements, one per line. + +Formatted text fields use the same rules as the long description in +a package's `Description` field, possibly also using the first +line as a synopsis, like `Description` uses it for the +short description. +See section 5.6.13, Description, at +http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description +for details. +For example, `Disclaimer` has no special first line, whereas +`License` does. + # Implementation ## Sections ### Header Section (Once) @@ -77,6 +107,7 @@ * **`Format`** * Required * Single occurrence + * Value: single line * Syntax: URI of the format specification, such as: * http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=filerev=REVISION * Note that the unwieldy length of the URL should be solved in @@ -86,12 +117,14 @@ * **`Upstream-Name`** * Optional * Single occurrence + * Value: single line * Syntax: Single line (in most cases a single word), containing the name upstream uses for the software. * **`Upstream-Contact`** * Optional * Single occurrence + * Value: line based list * Syntax: Line(s) containing the preferred address(es) to reach the upstream project. May be free-form text, but by convention will usually be written as a list of RFC2822 addresses or URIs. @@ -99,13 +132,15 @@ * **`Source`** * Optional * Single occurrence - * Syntax: One or more URIs, one per line, indicating the primary - point of distribution of the software. + * Value: line based list + * Syntax: One or more URIs, indicating the primary + points of distribution of the software. * **`Disclaimer`** * Optional * Single occurrence - * Syntax: Free-form text. On Debian systems, this field can be + * Value: formatted text, no synopsis + * Syntax: On Debian systems, this field can be used in the case of non-free and contrib packages (see [Policy 12.5]( http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile)) @@ -132,13 +167,15 @@ * Required for all but the first paragraph. If omitted from the first paragraph, this is equivalent to a value of '*'. + * Value: white space separated list * Syntax: List of patterns indicating files covered by the license and copyright specified in this paragraph. See File patterns below. * **`Copyright`** * Required - * Syntax: one or more free-form copyright statement(s) that apply to - the files matched by the above pattern. + * Value: line based list + * Syntax: one or more free-form copyright statement(s), one per line, + that apply to the files matched by the above pattern. * Example value: 2008, John Q. Holder john.hol...@example.org * If a work has no copyright holder (i.e., it is in the public domain), that information should be recorded here. @@ -146,6 +183,7 @@ * **`License`** * Licensing terms for the files listed in **`Files`** field for this section * Required + * Value: formatted text, with synopsis * Syntax: * First line: an abbreviated name for the license (see *Short names* section for a list of standard abbreviations). If empty, it is
webchat/cgiirc on irc.debian.org
Who could help implement an interface/site faster and easier for users and contributors from Debian? Many more people could present this in the channels of the teams related to debian. It would also be an opportunity to help these people get together and do something for the project. The presence of unwanted people (trolls) may come to bother you, but you can have channel private or channel operators (@OP) to ban or punish this type of user. The proposal is to have something similar to http://webchat.freenode.net/ Using cgiirc on webchat.debian.org or irc.debian.org or .net This discussion has been raised in debian-www[1], but indicated that perhaps here would be the ideal way to get support. [1] http://old.nabble.com/Re%3A-cgiirc-on-irc.debian.org---p29322246.html -- ://ValessioBrito.info Comunicação e Tecnologia mobile: +55 71 VALESSIO -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100822233610.17057e8pnlc6i...@ssl.eumx.net
Re: webchat/cgiirc on irc.debian.org
On su, 2010-08-22 at 23:36 -0300, Valessio S Brito wrote: The proposal is to have something similar to http://webchat.freenode.net/ Using cgiirc on webchat.debian.org or irc.debian.org or .net The one place I know that advertises a web IRC gateway is the Koha project (http://koha-community.org/). I asked on their IRC channel, and their experiences have been quite positive. The least sophisticated people are unlikely to have much experience IRC, and probably won't have an IRC client installed, so having a web IRC client will make it easier for them to get help. I'm afraid I have idea what it would take to set this up and operate it, though. Does a free software implementation exist? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282533528.12989.433.ca...@havelock
Re: DEP-5: general file syntax
Lars Wirzenius l...@liw.fi writes: On la, 2010-08-21 at 01:58 -0700, Russ Allbery wrote: I was assuming that's how we'd get to a 1.1 version. I haven't read DEP-0 recently, though, so I guess I have a poor grasp of how this is supposed to work. I'll go review it. If we pick up the files in debian-policy, then wherever we publish them from should really publish the versions from the debian-policy package. I've reviewed it and undersand better now. DEP material is supposed to be incorporated into other documents where appropriate, rather than being maintained as a DEP. That was the bit that I was missing. I was assuming we'd have the current official version be in the debian-policy package, and published at http://www.debian.org/doc/ or http://www.debian.org/doc/debian-policy/ rather than on dep.debian.net. The final version of DEP-5 would have a pointer to the version in debian-policy. That's why I'm having such as bad time figuring out how to put the version in the URL. Yeah, that makes more sense. However, it now strikes me that the filename in debian-policy can just have the version number. So the filename would start out as copyright-format-1.0.txt, and when it changes, the the filename changes to copyright-format-1.1.txt. Does that sound reasonable? The URL for Format would then be something like http://www.debian.org/doc/packaging-manuals/copyright-format-1.0.html That's a bit long, perhaps. We might want to talk to debian-www about possible alternatives at some point (packaging-manuals is really long), but I think that's basically the right idea. Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ would fit easily in 80 columns, and I think we can probably generate the right directory structure for that. Something like: Format: http://www.debian.org/doc/standards/copyright-format/1.0/ would be even shorter, of course, but I don't know if it's worth the disruption. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hjic81b@windlord.stanford.edu
Re: webchat/cgiirc on irc.debian.org
On Mon, Aug 23, 2010 at 11:18 AM, Lars Wirzenius l...@liw.fi wrote: I'm afraid I have idea what it would take to set this up and operate it, though. Does a free software implementation exist? There are multiple web-based IRC clients and one or two Java applet ones, the only one available in Debian is cgiirc, which is not very Web 2.0 so is a little less friendly but works in many browsers. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktini+z=9pi-apx0bnt6e0-hjhrl2xdiopl1od...@mail.gmail.com
Re: DEP-5: general file syntax
Charles Plessy ple...@debian.org writes: I have mixed feelings about adding a extra level of complexity and introduce a syntax for lists. I think that apart from the Files field, the DEP could use mostly free-form values in the fields. In particular for the Copyright field, I am of the opinion that it should be free form and verbatim, preserving the newlines as they are in debian/copyright. If we use the same format everywhere, as proposed elsewhere, people can just add two spaces before the copyright statements to preserve the formatting. One minor problem is that Policy §5.1 specifies that if a field value may not be wrapped, then this field is a single line of white space separated data, and indeed there is no field in Policy's chapter 5 that is purely free-form while preserving newlines characters. I have opened #593909 to disambiguate this. The word wrapped in that context means folded, not wrapped in the sense that you're thinking of. But we'll talk about that more in that bug. Policy didn't use language very consistently. * **`Upstream-Name`** * Optional * Single occurrence + * Value: single line * Syntax: Single line (in most cases a single word), containing the name upstream uses for the software. * **`Upstream-Contact`** * Optional * Single occurrence + * Value: line based list * Syntax: Line(s) containing the preferred address(es) to reach the upstream project. May be free-form text, but by convention will usually be written as a list of RFC2822 addresses or URIs. The syntax of the Upstream-Contact field does not reflect the use intended by the Perl packaging team, which is to match a Debian package with a CPAN maintainer. The CPAN maintainer's email address not necessarly the preferred address to reach the upstream authors (for instance, a mailing list). I don't understand what you're concerned with here. It seems to match what they're doing now to me. Since this thread is not about the Upstream-* fields, let's not go too much in the details, except that in my opinion, ‘line based list’ is not the most appropriate format for the Upstream-Contact field's value. I like line-based list for this. @@ -99,13 +132,15 @@ * **`Source`** * Optional * Single occurrence + * Value: single line * Syntax: One or more URIs, one per line, indicating the primary point of distribution of the software. Since the syntax allows multiple URIs, and since the URIs may be long, I think that allowing newlines in the field will make it more readable. for instance by making it free-form (not formatted, see below). I agree with Lars on this. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739u6c7up@windlord.stanford.edu
