Re: upstream field in package description
Es geschah am Mittwoch 01 Juni 2005 21:58 als Chris Waters schrieb: On Wed, Jun 01, 2005 at 04:08:54PM +0200, Christian Schoenebeck wrote: Because if it would get part of the policy to be mandatory , then developers would get stressed or at least noticed/pointed to by (hopefully policy-updated) packaging scripts. You misunderstand the purpose of policy. Policy is not a club to beat developers. The purpose of policy is to decide which packages are so buggy that they should be removed from the archive before release! My intention is not to beat anybody. My proposal was an top-down approach, being the policy a guideline for packagers. You're putting the cart before the horse. Get the packages to change, and THEN we'll consider changing policy to match. Well, your suggestion sounds to me like putting the cart before the horse. If getting the packages to change would easily realisable then there would be no need for a policy. How should I ever get packagers to accept my proposal when there's no guideline covering it? Opening a wishlist item against every single package? No Debian maintainer would ever add a new, undocumented field, which actually makes sense, because what if everybody adds his own fields, or even worse - adding the same information with different field names? I would call that chaos and that's why it should be specified - by the policy. Ok, seems I cannot convince anybody here. That just proofs me once again that moving something in Debian is almost impossible, at least if you are not a VIP. Shutting up now CU Christian P.S. please CC me as I'm offlist ! (and no, my email client doesn't offer Mail-Followup-To header field) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: upstream field in package description
Christian Schoenebeck [EMAIL PROTECTED] writes: Well, your suggestion sounds to me like putting the cart before the horse. If getting the packages to change would easily realisable then there would be no need for a policy. How should I ever get packagers to accept my proposal when there's no guideline covering it? Get a check into lintian. Some of us are obsessive about keeping packages lintian-clean. :) I don't know what the criteria is for lintian checks, but I would guess that a general consensus on debian-devel would produce a strong argument in favor of a check. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: upstream field in package description
On Wed, Jun 01, 2005 at 01:31:27AM +0200, Christian Schoenebeck wrote: Es geschah am Mittwoch 01 Juni 2005 01:33 als Bill Allombert schrieb: 1) Debian Policy mandate the information in the copyright file already: 12.5. Copyright information --- ... In addition, the copyright file must say where the upstream sources (if any) were obtained. It should name the original authors of the package and the Debian maintainer(s) who were involved with its creation. Not sufficient IMO. Again; you need to download and/or install the package to get that information. Not true. The copyright files are available on packages.debian.org. 2) Developers-reference propose the following: 6.2.4. Upstream home page - We recommend that you add the URL for the package's home page to the package description in `debian/control'. This information should be added at the end of description, using the following format: . Homepage: http://some-project.some-place.org/ The 'good' thing about recommendations is that they can be ignored so easily and in this case this specific recommendation is ignored by the majority of all Debian packages! What would yours not be ignored even more ? The Developers-reference proposal allow a stable user to go to package.debian.org to read the description of the unstable version of the package and get a more up-to-date information. ... where he could also read a Upstream-Source: field generated information... Homepage has the merit to be already implemented. 4) Some upstream authors do not want their email address to be exposed. To their defense, someone buying the getithere.org domain might be surprised to receive spams addressed to the foocrew user. Upstream-Source: neglected or Upstream-Source: undesired or even Upstream-Author: restricted or whatever. All those contra arguments depend on a clear minority of packages and as you can see can still live with my proposal. You failed to identify a single point where Upstream-Source is better than Homepage. That missing upstream information is really annoying! That is no excuse. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: upstream field in package description
Es geschah am Mittwoch 01 Juni 2005 15:12 als Bill Allombert schrieb: On Wed, Jun 01, 2005 at 01:31:27AM +0200, Christian Schoenebeck wrote: Es geschah am Mittwoch 01 Juni 2005 01:33 als Bill Allombert schrieb: 1) Debian Policy mandate the information in the copyright file already: 12.5. Copyright information --- ... In addition, the copyright file must say where the upstream sources (if any) were obtained. It should name the original authors of the package and the Debian maintainer(s) who were involved with its creation. Not sufficient IMO. Again; you need to download and/or install the package to get that information. Not true. The copyright files are available on packages.debian.org. And the user should be forced to go to packages.debian.org to get hat information? You seriously think this is a *good* solution? IMO the Debian servers should be discharged as much as possible as there is already more than enough load on them and adding some bytes per package for the upstream source isn't really a deal, is it? Also from the user's perspective I just find it logical to expect to get the upstream source with 'apt-cache show'. 6.2.4. Upstream home page - We recommend that you add the URL for the package's home page to the package description in `debian/control'. This information should be added at the end of description, using the following format: . Homepage: http://some-project.some-place.org/ The 'good' thing about recommendations is that they can be ignored so easily and in this case this specific recommendation is ignored by the majority of all Debian packages! What would yours not be ignored even more ? [snip] You failed to identify a single point where Upstream-Source is better than Homepage. Because if it would get part of the policy to be mandatory , then developers would get stressed or at least noticed/pointed to by (hopefully policy-updated) packaging scripts. I think many developers aren't even aware of recommendation 6.2.4 and that's certainly the reason why the majority of packages do not provide it. And don't get me wrong; I dont care if this information is tagged as Homepage: or Upstream-Source: or whatever, as long as this information is provided, which is currently not seriously the case. But why would be an individual field be better than a pseudo field within the description section? I would have to ask why to _make_ it part of the description section? Why not adding Depends: and Version: also into the Description section? Excuse my irony, but this simply doesn't make sense to me, because the upstream source / homepage logically doesn't belong to the description section; it's an own information category and thus should be an own field. Which also makes it easier to get parsed and checked by scripts. That missing upstream information is really annoying! That is no excuse. Exactly, it's no excuse at all. Do you see any real problem with my proposal? I hope I showed you that all your contra arguments do not conflict with this proposal and I seriously think it improves quality of the Debian package information system. CU Christian P.S please CC me as I'm offlist ! (and no, my email client doesn't offer Mail-Followup-To header field) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: upstream field in package description
On Wed, Jun 01, 2005 at 04:08:54PM +0200, Christian Schoenebeck wrote: Because if it would get part of the policy to be mandatory , then developers would get stressed or at least noticed/pointed to by (hopefully policy-updated) packaging scripts. You misunderstand the purpose of policy. Policy is not a club to beat developers. The purpose of policy is to decide which packages are so buggy that they should be removed from the archive before release! You're putting the cart before the horse. Get the packages to change, and THEN we'll consider changing policy to match. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: upstream field in package description
Es geschah am Freitag 13 Mai 2005 22:15 als Adeodato Simó schrieb: * Christian Schoenebeck [Fri, 13 May 2005 21:41:46 +0200]: IMO at least the upstream source field should become mandatory for Debian packages in future. On some packages it's really not that easy to trace back the original upstream source, because not every maintainer is adding that to the copyright or README.Debian file. What do you think? That if a package does not contain those two bits of information in the copyright file (author and where to get the source), you should file a serious bug against the package, since the Debian Policy §12.5 mandates that such information must be present. I would like to ask for adding a new field to Debian package descriptions which defines the upstream source of a package, that is the location where the original sources were downloaded and probably optional as another field the upstream authors, like: Upstream-Source: http://www.getithere.org Upstream-Author: Foo Crew [EMAIL PROTECTED] Hence no need for this, its place is not the description but the copyright file, already. I just faced another big point for the proposal of forcing an upstream field in package descriptions in future policies; you have to download and install the respective package. E.g. I just wanted to see some screenshots of sketch a vector drawing application. I would have to install it to get the upstream URL. Even if there are packages which do not have an upstream URL (which are the absolute minory), then they could still simply provide something like: Upstream-Source: none or whatever. I really think this a very bad policy situation! CU Christian P.S. please CC me, I'm offlist!
Re: upstream field in package description
On Fri, May 13, 2005 at 09:41:46PM +0200, Christian Schoenebeck wrote: Hi! I would like to ask for adding a new field to Debian package descriptions which defines the upstream source of a package, that is the location where the original sources were downloaded and probably optional as another field the upstream authors, like: Upstream-Source: http://www.getithere.org Upstream-Author: Foo Crew [EMAIL PROTECTED] IMO at least the upstream source field should become mandatory for Debian packages in future. On some packages it's really not that easy to trace back the original upstream source, because not every maintainer is adding that to the copyright or README.Debian file. What do you think? 1) Debian Policy mandate the information in the copyright file already: 12.5. Copyright information --- ... In addition, the copyright file must say where the upstream sources (if any) were obtained. It should name the original authors of the package and the Debian maintainer(s) who were involved with its creation. 2) Developers-reference propose the following: 6.2.4. Upstream home page - We recommend that you add the URL for the package's home page to the package description in `debian/control'. This information should be added at the end of description, using the following format: . Homepage: http://some-project.some-place.org/ Note the spaces prepending the line, which serves to break the lines correctly. To see an example of how this displays, see http://packages.debian.org/unstable/text/docbook-dsssl.html. 3) Information about upstream website tend to get outdated, so stable packages are likely to include outdated informations. The Developers-reference proposal allow a stable user to go to package.debian.org to read the description of the unstable version of the package and get a more up-to-date information. 4) Some upstream authors do not want their email address to be exposed. To their defense, someone buying the getithere.org domain might be surprised to receive spams addressed to the foocrew user. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: upstream field in package description
Christian Schoenebeck [EMAIL PROTECTED] writes: Es geschah am Freitag 13 Mai 2005 22:15 als Adeodato Simó schrieb: Hence no need for this, its place is not the description but the copyright file, already. Right, but as a package description field it's easy to ensure (automatically) that this information is really provided. You can't seriously check that automatically on a README or copyright file. Well, you can if you require a particular format, but the main obstacle to both checking it in the control file and checking it in the copyright file is that not every package *has* an upstream author or upstream source. So it's not something that can be enforced uniformly. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: upstream field in package description
On May 13, Christian Schoenebeck [EMAIL PROTECTED] wrote: packages in future. On some packages it's really not that easy to trace back the original upstream source, because not every maintainer is adding that to the copyright or README.Debian file. Then open bugs on these packages, do not add useless pseudo-control headers (which also do not fit every package). -- ciao, Marco signature.asc Description: Digital signature
