Re: [devel-ref] author/homepage in description
Wichert Akkerman [EMAIL PROTECTED] writes: This does feel like a debian-devel or debian-project issue rather than a policy issue, too...? It is relevant to the discusison though.. do we want to bloat the Packages file with usptream author homepage information as well? Actually I was just proposing upstream homepage, but, yes, that's a very valid question. -- ...Adam Di Carlo..[EMAIL PROTECTED]...URL:http://www.onshored.com/
Re: [devel-ref] author/homepage in description
On Mon, Dec 16, 2002 at 12:12:08PM +0100, Wichert Akkerman wrote: Previously Adam DiCarlo wrote: Well, before I venture on this, is there a way we can store certain data in control.tar.gz or something but without bloating the Packages file? No. Well, strictly, there obviously is: postinsts don't end up in Packages.gz after all. It doesn't make any sense for this though. It is relevant to the discusison though.. do we want to bloat the Packages file with usptream author homepage information as well? The Packages file is mainly meant to be all the information you should need to work out whether you want to install a package or not: description, what other packages you need, a file name to download, etc. A More-Info-URL: field might make sense here in that it'd let you find out more about the package, see screeenshots and so forth. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Australian Linux Lovefest Heads West'' -- linux.conf.au, Perth W.A., 22nd-25th January 2003
Re: [devel-ref] author/homepage in description
Hello, There is something I believe should be done anyway: split the Packages file in Packages and Descriptions files as follows: Remove the extended description from the Packages and put them in a separated Descriptions file. (for clarity I have named Packages1 the Packages before removing description and Packages2 after the removal. In practice Packages2 should be named Packages, of course) Benefit: 1) People running sid could update theirs Descriptions files much less frequently that the Packages2 files, saving badwidth. 2) People with modem have much less mandatory data to download. 3) People using the translated descriptions are no more required to download the english version. Implementation: There is several way to implement that with keeping full backward compatibility. 1) Add dummy long description to the Packages2 files so that it is a valid old-fashioned Packages1 file. 2.0) patch apt-get to rebuild the Packages1 from the Descriptions and Packages2 files. 2.1) or fix all the programs that need the extended descriptions, much harder. We can use the short description as a dummy long description, or use md5sum so that we can detect when the description in Descriptions is not up to date. Once this is in place, we can start adding custom field to Descriptions without bloating the Packages files. Cheers, -- Bill. [EMAIL PROTECTED]
Re: [devel-ref] author/homepage in description
Wichert Akkerman [EMAIL PROTECTED] writes: Previously Adam DiCarlo wrote: Comments desired. Perhaps it makes sense to think about all fields people would possible want. The rpm format for example has a license field. Is that something that people would like to see for deb as well? Well, before I venture on this, is there a way we can store certain data in control.tar.gz or something but without bloating the Packages file? It seems to me that the hugeness of the Packages file is one of the largest scalability constraints in the Debian archive (thinking of user download times here) and we need to be very respectful of keeping its size down. There are perhaps some fields users would always want in the normal context (md5sum and all that) and some which are rather specialized (and the homepage thing goes in this latter category). This does feel like a debian-devel or debian-project issue rather than a policy issue, too...? -- ...Adam Di Carlo..[EMAIL PROTECTED]...URL:http://www.onshored.com/
Re: [devel-ref] author/homepage in description
Previously Adam DiCarlo wrote: Well, before I venture on this, is there a way we can store certain data in control.tar.gz or something but without bloating the Packages file? No. This does feel like a debian-devel or debian-project issue rather than a policy issue, too...? It is relevant to the discusison though.. do we want to bloat the Packages file with usptream author homepage information as well? Wichert. -- Wichert Akkerman [EMAIL PROTECTED] http://www.wiggy.net/ A random hacker
Re: [devel-ref] author/homepage in description
On Mon, 16 Dec 2002 12:12:08 +0100 Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Adam DiCarlo wrote: Well, before I venture on this, is there a way we can store certain data in control.tar.gz or something but without bloating the Packages file? No. Well, not with existing practices. This does feel like a debian-devel or debian-project issue rather than a policy issue, too...? It is relevant to the discusison though.. do we want to bloat the Packages file with usptream author homepage information as well? All data is important, but it has to be sorted/classified to be most usefull. We currently treat all package metadata as being equally important, this is inefficient. Our various metadata fields have a few different targets. System-state: Package, Version, Status, Conffiles These fields are unique to each installation, if the these are backed up all other metadata can be recovered. System-dependencies: Essential, Pre-Depends, Depends, Conflicts, Provides, Replace. These fields and the system-state fields are required before a package's state can be safely changed (added/removed) Administration: Source, Architecture, Filename, md5sum, Size, Maintainer These are to assist in distribution/storage of packages. User: Priority, Section, Installed-Size, Description, Task, Recommends, Suggests, Enhances. These fields are to assist the user in choosing which packages to install. The real cause of Packages bloat is not that there is too much metadata, it is that we constantly send duplicate information. We should not be trying to reduce the amount of metdata available to users, we should be trying to find more efficient ways to get that information to them. If we made the metdata for an individual package available seperatly then users would only need to download metadata when its changed. This approach does introduce efficiency problems of transmitting small files, but after a few updates it would pay for itself. If we split a packages metadata into multiple parts once it was downloaded we could more easily target the needs of different packaging tools. Storing lots of small files locally uses more disk space, this could be overcome by splitting/joinging and/or compression on the different types of metdata. Glenn
Re: [devel-ref] author/homepage in description
On Mon, Dec 16, 2002 at 12:12:08PM +0100, Wichert Akkerman wrote: Previously Adam DiCarlo wrote: Well, before I venture on this, is there a way we can store certain data in control.tar.gz or something but without bloating the Packages file? No. Well, why not? All it would take would be for apt-ftparchive/dpkg-scanpackages to not copy the relevant fields into the Packages file; would this break anything? (and if so, can we fix it?) Of course, this approach is only interesting for data that isn't needed frequently in advance. On a related note, since control.tar.gz is packed into the ar archive before data.tar.gz, a sufficiently intelligent http client can acquire just that portion of the package on demand. [Note, I'm not convinced that this is a useful thing to do, just wondering whether it is possible] -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpXMIBRi65Ed.pgp Description: PGP signature
Re: [devel-ref] author/homepage in description
On Mon, Dec 16, 2002 at 05:00:33AM -0600, Adam DiCarlo wrote: Comments desired. Perhaps it makes sense to think about all fields people would possible want. The rpm format for example has a license field. Is that something that people would like to see for deb as well? Well, before I venture on this, is there a way we can store certain data in control.tar.gz or something but without bloating the Packages file? But the packages.d.o web pages use exactly those files as input. :) It seems to me that the hugeness of the Packages file is one of the largest scalability constraints in the Debian archive (thinking of user download times here) and we need to be very respectful of keeping its size down. There are perhaps some fields users would always want in the normal context (md5sum and all that) and some which are rather specialized (and the homepage thing goes in this latter category). Since the extended description is still there, and it's unrestrained as far as size goes, it doesn't really matter much if we ban further one-liner fields like one for URL... -- 2. That which causes joy or happiness.
Re: [devel-ref] author/homepage in description
Previously Andrew Suffield wrote: Well, why not? All it would take would be for apt-ftparchive/dpkg-scanpackages to not copy the relevant fields into the Packages file; would this break anything? (and if so, can we fix it?) It will break all existing dselect methods for example that exepect all the data to be in the Packages files. Wichert. -- Wichert Akkerman [EMAIL PROTECTED] http://www.wiggy.net/ A random hacker
Re: [devel-ref] author/homepage in description
On Mon, Dec 16, 2002 at 12:12:08PM +0100, Wichert Akkerman wrote: This does feel like a debian-devel or debian-project issue rather than a policy issue, too...? It is relevant to the discusison though.. do we want to bloat the Packages file with usptream author homepage information as well? As far as home pages are concerned, the numbers speak for themselves: % apt-cache dumpavail | grep http:// -c 1171 The question is no longer do we want this, it's how we want this. -- 2. That which causes joy or happiness.
Re: [devel-ref] author/homepage in description
I did some quick math to see how much a Packages file will grow if we add a Homepage URL. The number of unique URLs currently being used: [tornado;~]-32 grep http: /var/lib/dpkg/available | sed -e 's/.*\(http:[^[:space:]]*\).*/\1/' | sort | uniq | wc -l 744 The amount of data currently used by URLs: [tornado;~]-33 grep http: /var/lib/dpkg/available | sed -e 's/.*\(http:[^[:space:]]*\).*/\1/' | sort | uniq | wc -c 25919 The total number of available packages: [tornado;~]-34 grep -c '^Package:' /var/lib/dpkg/available 11516 From this data we can calculate the average size of a URL: 25919 / 744 = 34.837 characters. If we use the name Homepage as field name that means we will end up using 11516 * (10 + 34.837) = 516342.892 or approximately 504 kilobyte of data. As a result of this the Packages file will increase 516343 - 25919 = 490424 bytes, or around 479 kilobyte. That is a lot of data for people using modems. Wichert. -- Wichert Akkerman [EMAIL PROTECTED] http://www.wiggy.net/ A random hacker
Re: [devel-ref] author/homepage in description
On Mon, 16 Dec 2002, Wichert Akkerman wrote: I did some quick math to see how much a Packages file will grow if we add a Homepage URL. As a result of this the Packages file will increase 516343 - 25919 = 490424 bytes, or around 479 kilobyte. That is a lot of data for people using modems. Isn't Packages compressed when apt-get downloads it? Looking at woody's Packages.gz, it's compressed about 5:1, so I would expect this new homepage tag to compress at least equally well, turning this into a 100kb expansion. Mike
Re: [devel-ref] author/homepage in description
Previously Mike Dresser wrote: Isn't Packages compressed when apt-get downloads it? Looking at woody's Packages.gz, it's compressed about 5:1, so I would expect this new homepage tag to compress at least equally well, turning this into a 100kb expansion. Depends on the dselect method I think, but the most popular one by far (apt) indeeds uses the compressed version. Wichert. -- Wichert Akkerman [EMAIL PROTECTED] http://www.wiggy.net/ A random hacker
Re: [devel-ref] author/homepage in description
On 16-Dec-02, 11:47 (CST), Josip Rodin [EMAIL PROTECTED] wrote: (Besides, that calculation assumes things like all developers doing it and all packages having it.) That's probably a reasonable assumption. As soon as such a field exists, some enterprising young person will generate wishlist bug reports against every package in the archive that doesn't have them, and since it's a reasonable request, probably the next upload will have a field. Even packages that don't have a useful homepage will have to put something like Homepage: N/A to prevent repeated stupid bugreports. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: [devel-ref] author/homepage in description
On Mon, Dec 16, 2002 at 01:54:04PM -0600, Steve Greenland wrote: (Besides, that calculation assumes things like all developers doing it and all packages having it.) That's probably a reasonable assumption. As soon as such a field exists, some enterprising young person will generate wishlist bug reports against every package in the archive that doesn't have them, and since it's a reasonable request, probably the next upload will have a field. Even packages that don't have a useful homepage will have to put something like Homepage: N/A to prevent repeated stupid bugreports. Those things can only happen if we phrase policy very, _very_ badly. I don't believe anyone will do that -- did you notice any bug reports e.g. about lacking Build-Depends on packages that don't have them? I didn't, and I have at least one such package. -- 2. That which causes joy or happiness.
Re: [devel-ref] author/homepage in description
Previously Josip Rodin wrote: 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-//. Not necessarily need, the XK field would still work but there would just be a new preferred way of setting that data. Tools that parse this data will not notice the difference. Wichert. -- Wichert Akkerman [EMAIL PROTECTED] http://www.wiggy.net/ A random hacker
Re: [devel-ref] author/homepage in description
Previously Adam DiCarlo wrote: Comments desired. Perhaps it makes sense to think about all fields people would possible want. The rpm format for example has a license field. Is that something that people would like to see for deb as well? I'ld rather make all such changes at once. Wichert. -- Wichert Akkerman [EMAIL PROTECTED] http://www.wiggy.net/ A random hacker
Re: [devel-ref] author/homepage in description
On Sun, Dec 15, 2002 at 11:37:56AM +0100, Wichert Akkerman wrote: 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-//. Not necessarily need, the XK field would still work but there would just be a new preferred way of setting that data. Tools that parse this data will not notice the difference. Yes, they will, they will require me to have a chunk of backwards compatibility code :P Why can't we all just get along^W^W do the right thing now, instead of these pointless workarounds... -- 2. That which causes joy or happiness.
Re: [devel-ref] author/homepage in description
On Thu, Dec 12, 2002 at 12:48:33AM +, Colin Watson wrote: On Wed, Dec 11, 2002 at 10:57:48PM +0100, Luca - De Whiskey's - De Vitis wrote: homepage://some.site.org/some/index.html snapshot://some.site.org/some/snapshot.png URI schemes are not to be used as a means of expressing the purpose of the URI. I was refering to wikiwiki like system i sow someware. Indeed you are right. So what about this: Package: Foo Description: bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla . Homepage: http://some.site.org/some/index.html Snapshot: http://some.site.org/some/snapshot.png We don't modify the control file sysntax but include the link we want, in a way we can parse and reuse. If we use this side by side with the copyright file format, we'll be able to show users almost anything they would like to konw about the package ((Upstream-(Source|Authors)|Copyright) are useful information, but probably only some expert user would care about them) ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][-A-Za-z]*[iy]'?s$ | as fine or rude sentences have Infinite loop: see `Loop, infinite'.| something in common: they Loop, infinite: see `Infinite loop'.| don't depend on the language.
Re: [devel-ref] author/homepage in description
On Wed, Dec 11, 2002 at 10:57:48PM +0100, Luca - De Whiskey's - De Vitis wrote: Yes, but that means extraction of possibly huge data.tar.gz, versus extracting a much tinier control.tar.gz. I can't tell it for sure, but a c program that only extracting such a file should not be so slow, or at least not slower than tar it self. Yes, but tar itself is slow for this, am I not making myself clear here? Example 1: open a 80 MB deb, skip over a control.tar.gz, extract a 50 MB data.tar.gz, skip over a couple of thousand files (49 MB total size), extract usr/share/doc/foo/copyright, and then read and parse it. Example 2: open a 80 MB deb, extract control.tar.gz, read and parse control file. Isn't the latter saner? URIs are not descriptive for the binary package management, so it's my _opinion_ (!standards) that there should not be one specific field into the package control file. Of course, i would not remove the extended description. That doesn't follow. The extended description is as descriptive for the binary package management (whatever you mean by that) as the home page URL is. If we want to include homepage or snapshot into the package control files, we may use `home made' protocols in Description: field like: homepage://some.site.org/some/index.html snapshot://some.site.org/some/snapshot.png bugs://some.site.org/some/bug/report/system/ Or whatever. These may easily be parsed and used on packages.debian.org. What about this? Like Colin said, those aren't quite protocols... I still think that a simple additional field is the simplest solution. -- 2. That which causes joy or happiness.
Re: [devel-ref] author/homepage in description
On Tue, Dec 10, 2002 at 02:01:36PM -0800, Chris Waters 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. I'm just generally against the let's do this now even if we know for a fact it's technically suboptimal, only not done because of trifle details, and will cause us extra work later attitude. The new field should be done properly ASAP; the developers' reference can document the existing practice of putting this stuff in the Description: field, but if we have a consensus to make a new field, then we should do that, not concentrate on workarounds. -- 2. That which causes joy or happiness.
Re: [devel-ref] author/homepage in description
On Wed, Dec 11, 2002 at 09:18:05AM +0100, Josip Rodin wrote: The new field should be done properly ASAP; the developers' reference can document the existing practice of putting this stuff in the Description: field, but if we have a consensus to make a new field, then we should do that, not concentrate on workarounds. Now I'm confused -- it sounds like we're in complete agreement. :) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: [devel-ref] author/homepage in description
On Tue, Dec 10, 2002 at 02:01:36PM -0800, Chris Waters wrote: 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. How about a more general thing, called URL. It can then be a homepage, ftp-site,goopher or anything similar. Regards, // Ola -- 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] -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: [devel-ref] author/homepage in description
Hello developers, Policy already mandate upstream site in copyright, and it work: try grep '\(f\|ht\)tp://' /usr/share/doc/*/copyright In fact grep -A1 '^It was downloaded from' /usr/share/doc/*/copyright output a result for half of the packages on my system. Why not: 1) Document this feature: state that the upstream url must be matched by grep '^\(It was downloaded\|fromUpstream-URL:\)' copyright or something similar. 2) Add link to copyright files in packages.debian.org. I think it is already worked on. 3) Optionnally, use the mechanism above to add a link in packages.debian.org It may look like a kludge, but it follow current policy and current practice and can work *today*. Cheers, -- Bill. [EMAIL PROTECTED] Ad Majorem Debian Gloriam
Re: [devel-ref] author/homepage in description
On Wed, Dec 11, 2002 at 03:14:15PM +0100, Bill Allombert wrote: Hello developers, Policy already mandate upstream site in copyright, and it work: try grep '\(f\|ht\)tp://' /usr/share/doc/*/copyright [...] $ grep '\(f\|ht\)tp://' /usr/share/doc/debian-policy/copyright http://www.pathname.com/fhs/. But http://www.pathname.com/fhs/. does have no mention of this package. Denis
Re: [devel-ref] author/homepage in description
On Wed, Dec 11, 2002 at 03:14:15PM +0100, Bill Allombert wrote: Policy already mandate upstream site in copyright, and it work: try grep '\(f\|ht\)tp://' /usr/share/doc/*/copyright 2) Add link to copyright files in packages.debian.org. I think it is already worked on. This requires expanding source packages. Doing this for the mere purpose of getting the URIs is downright stupid. -- 2. That which causes joy or happiness.
Re: [devel-ref] author/homepage in description
On Wed, Dec 11, 2002 at 03:23:57PM +0100, Denis Barbier wrote: On Wed, Dec 11, 2002 at 03:14:15PM +0100, Bill Allombert wrote: Hello developers, Policy already mandate upstream site in copyright, and it work: try grep '\(f\|ht\)tp://' /usr/share/doc/*/copyright [...] $ grep '\(f\|ht\)tp://' /usr/share/doc/debian-policy/copyright http://www.pathname.com/fhs/. But http://www.pathname.com/fhs/. does have no mention of this package. debian-policy copyright state that: ... The FHS and FSSTND documents were downloaded from http://www.pathname.com/fhs/. ... FHS is included of the debian-policy package and truly http://www.pathname.com/fhs/ is the site of one of the upstream author of some files in the debian-policy packages. I have never proposed to blindly do grep '\(f\|ht\)tp://', it was to make an estimate of the number of package with upstream URL in the copyright file. Extraneous data do not harm, so sorry if I did not understand your point. Cheers, -- Bill. [EMAIL PROTECTED] Ad Majorem Debian Gloriam
Re: [devel-ref] author/homepage in description
Joy write : On Wed, Dec 11, 2002 at 03:14:15PM +0100, Bill Allombert wrote: Policy already mandate upstream site in copyright, and it work: try grep '\(f\|ht\)tp://' /usr/share/doc/*/copyright 2) Add link to copyright files in packages.debian.org. I think it is already worked on. This requires expanding source packages. Doing this for the mere purpose of getting the URIs is downright stupid. [Can it be extracted from the binary packages instead ?] So you are not interested to add a link to copyright files in packages.debian.org ? And you would only go for putting the URL in the Packages files, so that you do not need to extract packages? Anyway you have a valid point, but having the data in the binary package instead of the Packages file would be OK for me. Cheers, -- Bill. [EMAIL PROTECTED] Ad Majorem Debian Gloriam
Re: [devel-ref] author/homepage in description
On Tue, 10 Dec 2002, Chris Waters wrote: If I have any remaining reservations about this proposal, it's that homepage is not (yet) an English word, IMO. Neither is 'Debian'. Now for goodness' sake -- grow up. -- Martin Wheeler - StarTEXT / AVALONIX - Glastonbury - BA6 9PH - England [EMAIL PROTECTED] http://startext.demon.co.uk/ GPG pub key : 8D6B948B ECC6 D98E 4CC8 60E3 7E32 D594 BB27 3368 8D6B 948B - Share your knowledge. It's a way of achieving immortality. -
Re: [devel-ref] author/homepage in description
On Wed, Dec 11, 2002 at 03:27:37PM +0100, Josip Rodin wrote: On Wed, Dec 11, 2002 at 03:14:15PM +0100, Bill Allombert wrote: Policy already mandate upstream site in copyright, and it work: try grep '\(f\|ht\)tp://' /usr/share/doc/*/copyright 2) Add link to copyright files in packages.debian.org. I think it is already worked on. This requires expanding source packages. Doing this for the mere purpose of getting the URIs is downright stupid. It could be useful to read the copyright too, and copyright file can be extracted from the binary packages. Give the copiright file 4 trivial tags, and I'll be hapy to play with them for you. Packaged: date packagers Upstream-Authors: author longer_list Upstream-URI: URI Copyright: sinopsys license Easy to check, change, extract from binary packages... why not? -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][-A-Za-z]*[iy]'?s$ | as fine or rude sentences have Infinite loop: see `Loop, infinite'.| something in common: they Loop, infinite: see `Infinite loop'.| don't depend on the language.
Re: [devel-ref] author/homepage in description
On Wed, Dec 11, 2002 at 04:50:26PM +, Martin Wheeler wrote: If I have any remaining reservations about this proposal, it's that homepage is not (yet) an English word, IMO. Neither is 'Debian'. Yes, but we didn't choose this name. This is not 1993, we get to have a discussion about names, too! :) Now for goodness' sake -- grow up. I object to that proposal: I like xtifr better when he's slightly childish. :) (Not that the above is necessarily childish, just in general.) And while we're at crass suggestions -- chill out. -- 2. That which causes joy or happiness.
Re: [devel-ref] author/homepage in description
On Wed, Dec 11, 2002 at 06:04:26PM +0100, Luca - De Whiskey's - De Vitis wrote: Policy already mandate upstream site in copyright, and it work: try grep '\(f\|ht\)tp://' /usr/share/doc/*/copyright 2) Add link to copyright files in packages.debian.org. I think it is already worked on. This requires expanding source packages. Doing this for the mere purpose of getting the URIs is downright stupid. It could be useful to read the copyright too, and copyright file can be extracted from the binary packages. Give the copiright file 4 trivial tags, and I'll be hapy to play with them for you. Packaged: date packagers Upstream-Authors: author longer_list Upstream-URI: URI Copyright: sinopsys license Easy to check, change, extract from binary packages... why not? If you define easy as within reach of dpkg-deb -x... I don't. dpkg-deb -I is easy. Also, it would mean chaging from non-regulated copyright files to regulated copyright files, with URIs; as opposed to the change from current set of metadata fields to current set of metadata fields plus a field for URIs. The latter is much less intrusive. -- 2. That which causes joy or happiness.
Re: [devel-ref] author/homepage in description
On Wed, Dec 11, 2002 at 07:25:14PM +0100, Josip Rodin wrote: If you define easy as within reach of dpkg-deb -x... I don't. dpkg-deb -I is easy. I may not have undestood, but you don't need to extract the package: if you want a quick way to have the copyright file, you can unpack the package with `ar' and extract the file from data.tar.gz. I never needed this, but i think there are some libraries to access ar archives and then the tar archive from a c program (and probably from other languages). Also, it would mean chaging from non-regulated copyright files to regulated copyright files, with URIs; as opposed to the change from current set of metadata fields to current set of metadata fields plus a field for URIs. The latter is much less intrusive. I would prefer the first, even if it is more intrusive. IMHO an URI filed does not make sense in the package control file, and formatting a source of information (like the copyright file) makes it more accessible. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][-A-Za-z]*[iy]'?s$ | as fine or rude sentences have Infinite loop: see `Loop, infinite'.| something in common: they Loop, infinite: see `Infinite loop'.| don't depend on the language.
Re: [devel-ref] author/homepage in description
On Wed, Dec 11, 2002 at 08:40:08PM +0100, Luca - De Whiskey's - De Vitis wrote: If you define easy as within reach of dpkg-deb -x... I don't. dpkg-deb -I is easy. I may not have undestood, but you don't need to extract the package: if you want a quick way to have the copyright file, you can unpack the package with `ar' and extract the file from data.tar.gz. I never needed this, but i think there are some libraries to access ar archives and then the tar archive from a c program (and probably from other languages). Yes, but that means extraction of possibly huge data.tar.gz, versus extracting a much tinier control.tar.gz. IMHO an URI filed does not make sense in the package control file, By what standards? Would you remove the extended description as well, then? -- 2. That which causes joy or happiness.
Re: [devel-ref] author/homepage in description
On Wed, Dec 11, 2002 at 09:30:51PM +0100, Josip Rodin wrote: Yes, but that means extraction of possibly huge data.tar.gz, versus extracting a much tinier control.tar.gz. I can't tell it for sure, but a c program that only extracting such a file should not be so slow, or at least not slower than tar it self. (As soon as i'll have some time i'll write one and possibly let you know, if you like). IMHO an URI filed does not make sense in the package control file, By what standards? Would you remove the extended description as well, then? Just to be sure: we were talking about including an (upstream_source|snapshot|homepage) URI field into the package control file. Isn't it? I did not mean an URI _into_ a field (like URIs into Description), but a general field which would only contain a URI. URIs are not descriptive for the binary package management, so it's my _opinion_ (!standards) that there should not be one specific field into the package control file. Of course, i would not remove the extended description. If we want to include homepage or snapshot into the package control files, we may use `home made' protocols in Description: field like: homepage://some.site.org/some/index.html snapshot://some.site.org/some/snapshot.png bugs://some.site.org/some/bug/report/system/ Or whatever. These may easily be parsed and used on packages.debian.org. What about this? ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][-A-Za-z]*[iy]'?s$ | as fine or rude sentences have Infinite loop: see `Loop, infinite'.| something in common: they Loop, infinite: see `Infinite loop'.| don't depend on the language.
Re: [devel-ref] author/homepage in description
On Wed, Dec 11, 2002 at 03:14:15PM +0100, Bill Allombert wrote: Policy already mandate upstream site in copyright, and it work: The location of the source is not necessarily the same as the project home page (assuming there is a project home page). Small projects especially may have a home page hosted on the author's ISP, but may simply throw the source onto one of the large sites like simtel. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: [devel-ref] author/homepage in description
On Wed, Dec 11, 2002 at 06:29:22PM +0100, Josip Rodin wrote: On Wed, Dec 11, 2002 at 04:50:26PM +, Martin Wheeler wrote: [re: my statement that homepage is not (yet) a word.] Neither is 'Debian'. Yes, but we didn't choose this name. More to the point, names aren't necessarily supposed to be words. So the attempted rebuttal is moot. Now for goodness' sake -- grow up. I object to that proposal: I like xtifr better when he's slightly childish. :) Um, thanks, I think? At my age, it's probably too late to attempt to implement any such plan. Furthermore, once the grey hairs appear (as they're just beginning to in my case), the proposition of growing up starts to seem much less appealing. :) Anyway, to get back on topic for a sec, I'm not a grammar nazi. I didn't object to homepage, I merely expressed reservations. And if I really cared, I would have offered some alternatives. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: [devel-ref] author/homepage in description
My only problem with using the download location URL is not a technical one, but rather than download locations are not software home pages, and the one can't in all cases be derived from the other. -- ...Adam Di Carlo..[EMAIL PROTECTED]...URL:http://www.onshored.com/
Re: [devel-ref] author/homepage in description
On Wed, Dec 11, 2002 at 10:57:48PM +0100, Luca - De Whiskey's - De Vitis wrote: I did not mean an URI _into_ a field (like URIs into Description), but a general field which would only contain a URI. URIs are not descriptive for the binary package management, so it's my _opinion_ (!standards) that there should not be one specific field into the package control file. Of course, i would not remove the extended description. If we want to include homepage or snapshot into the package control files, we may use `home made' protocols in Description: field like: homepage://some.site.org/some/index.html snapshot://some.site.org/some/snapshot.png Certainly both of these are useless, as they fail to define a protocol in any meaningful way. (http: and ftp: are both valid and different for those examples.) Even if they were defined they would almost certainly just be aliases for other protocols, and thus would be misuses of the scheme part of URIs. URI schemes are not to be used as a means of expressing the purpose of the URI. bugs://some.site.org/some/bug/report/system/ That might be useful, but only if a bug-reporting URI scheme were defined and distinct from existing schemes. -- Colin Watson [EMAIL PROTECTED]
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
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
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
Re: [devel-ref] author/homepage in description
On Sun, Dec 08, 2002 at 09:43:00PM -0600, Adam DiCarlo wrote: Colin Watson [EMAIL PROTECTED] writes: We could just use the existing support for user-defined fields for a while though. Oh ! Where can I read about these? They aren't mentioned in deb-control(5) or /usr/share/doc/dpkg nor /usr/share/doc/dpkg-dev ... I think they're in an obscure place in policy somewhere, possibly in the appendices from the old packaging manual. At any rate, 'XB-Upstream-Homepage:' in a binary stanza in debian/control leads to 'Upstream-Homepage:' being in the binary package's control file. The point was validly raised in a previous thread that using these means changing packages twice in the event that dpkg is eventually changed. -- Colin Watson [EMAIL PROTECTED]
Re: [devel-ref] author/homepage in description
Colin Watson [EMAIL PROTECTED] writes: On Sun, Dec 08, 2002 at 09:43:00PM -0600, Adam DiCarlo wrote: Colin Watson [EMAIL PROTECTED] writes: We could just use the existing support for user-defined fields for a while though. Oh ! Where can I read about these? They aren't mentioned in deb-control(5) or /usr/share/doc/dpkg nor /usr/share/doc/dpkg-dev ... I think they're in an obscure place in policy somewhere, possibly in the appendices from the old packaging manual. At any rate, 'XB-Upstream-Homepage:' in a binary stanza in debian/control leads to 'Upstream-Homepage:' being in the binary package's control file. Huh. I'll have to play around with this. I would indeed rather use a field, even a custom field, if possible, since this is really data. I'm hearing just go with homepage only, no other data really needed. I'll make that change. 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. The only nice thing about using the description is that it is already supported by packages.debian.org, whereas a custom field would obviously not be supported there. -- ...Adam Di Carlo..[EMAIL PROTECTED]...URL:http://www.onshored.com/
Re: [devel-ref] author/homepage in description
On Mon, Dec 09, 2002 at 01:17:28PM -0600, Adam DiCarlo wrote: [...] Huh. I'll have to play around with this. I would indeed rather use a field, even a custom field, if possible, since this is really data. I'm hearing just go with homepage only, no other data really needed. I'll make that change. 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. 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. Denis
Re: [devel-ref] author/homepage in description
On Mon, 9 Dec 2002, Denis Barbier wrote: On Mon, Dec 09, 2002 at 01:17:28PM -0600, Adam DiCarlo wrote: [...] Huh. I'll have to play around with this. I would indeed rather use a field, even a custom field, if possible, since this is really data. I'm hearing just go with homepage only, no other data really needed. I'll make that change. I don't like this. The pages listed will end up being wrong half the time and google can find homepages very well and everybody knows it, so what is the point in adding this? Britton Kerin
Re: [devel-ref] author/homepage in description
On Mon, Dec 09, 2002 at 12:31:48PM -0900, Britton wrote: I don't like this. The pages listed will end up being wrong half the time I think you exaggerate. Especially since this is optional (it's going in devel-ref as part of best-practices, not in policy as a requirement). So, if the maintainer knows that the home page is subject to change without notice, then he won't put it in the description. But many packages have home pages that haven't changed in decades, and aren't likely to. and google can find homepages very well and everybody knows it, so what is the point in adding this? Convenience. Someone browsing our package pages can just click through instead of jumping to google and manually typing in the package name (and maybe mistyping it). This works right now. And we could add a jump-to-homepage feature to dselect or aptitude in future, for further convenience. (Probably not in dselect, I admit.) Plus, google may not always help. if you search google for, say, rat, you're probably going to find more information about rodents than about the Debian package named rat. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: [devel-ref] author/homepage in description
Britton [EMAIL PROTECTED] writes: I don't like this. The pages listed will end up being wrong half the time Then file a minor bug. Half the time is a bit overstating, no? and google can find homepages very well and everybody knows it, so what is the point in adding this? Can you say user convenience ? Its a commonly requested feature and most everyone agrees this is useful. -- ...Adam Di Carlo..[EMAIL PROTECTED]...URL:http://www.onshored.com/
Re: [devel-ref] author/homepage in description
[EMAIL PROTECTED] (Denis Barbier) writes: 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. 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 don't think think this level of information for developers/contributors is appropriate for debian/control and pkg info. It's audience is too limited for the amount of bloat this will add to the repository. If anything, you could dictate this could be suggested or required in a /usr/share/doc/pkg/README or README.Debian file? -- ...Adam Di Carlo..[EMAIL PROTECTED]...URL:http://www.onshored.com/
Re: [devel-ref] author/homepage in description
On Mon, Dec 09, 2002 at 04:30:30PM -0600, Adam DiCarlo wrote: [...] I don't think think this level of information for developers/contributors is appropriate for debian/control and pkg info. It's audience is too limited for the amount of bloat this will add to the repository. If anything, you could dictate this could be suggested or required in a /usr/share/doc/pkg/README or README.Debian file? 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. Denis
Re: [devel-ref] author/homepage in description
On Mon, Dec 09, 2002 at 11:49:55PM +0100, Denis Barbier wrote: On Mon, Dec 09, 2002 at 04:30:30PM -0600, Adam DiCarlo wrote: [...] I don't think think this level of information for developers/contributors is appropriate for debian/control and pkg info. It's audience is too limited for the amount of bloat this will add to the repository. If anything, you could dictate this could be suggested or required in a /usr/share/doc/pkg/README or README.Debian file? 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. I doubt that translators will need to extract such information in an automatic manner. 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
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. Denis
Re: [devel-ref] author/homepage in description
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. The only nice thing about using the description is that it is already supported by packages.debian.org, whereas a custom field would obviously not be supported there. It's pretty much trivial for me to code support for a new field, and I certainly promise to do this if the field is implemented. -- 2. That which causes joy or happiness.
Re: [devel-ref] author/homepage in description
Adam DiCarlo wrote: Huh. I'll have to play around with this. I would indeed rather use a field, even a custom field, if possible, since this is really data. I'm hearing just go with homepage only, no other data really needed. I'll make that change. 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. The only nice thing about using the description is that it is already supported by packages.debian.org, whereas a custom field would obviously not be supported there. Colin's point is that if a lot of us modify our control files to use XB-Homepage or whatever, and then Homepage goes into policy as a truely supported field, then we all have to go back and remove the XB- from our control files. I think the best way to go ahead is get the field added to dpkg, then we can just start using it and go from there. The policy group prefers to document things that are already in use these days I understand. The dpkg maintainers have to be convinced to add it is all. In the meantime, anyone who doesn't mind revving a package later can get a jump on things with the XB- technique. If we can agree on a field name. While I've seen examples of Upstream-URL, Upstream-Homepage, etc., I'm partial to just Homepage. It indicates clearly that it is a web page, and it indicates what page the url is supposed to point to. It's also a term any use who sees it will immediatly understand. The Upstream seems redundant. Get a couple hundred packages using the field consistently and it'll really take care of itself. -- see shy jo pgpAxwsPAlabD.pgp Description: PGP signature
Re: [devel-ref] author/homepage in description
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. 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. 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. -- see shy jo pgpXZWd6hjzSW.pgp Description: PGP signature
Re: [devel-ref] author/homepage in description
Britton wrote: I don't like this. The pages listed will end up being wrong half the time and google can find homepages very well and everybody knows it, so what is the point in adding this? 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'd hope most maintainers are tuned in well enough to upstream development of their package to notice when its url changes. -- see shy jo pgp7U32zLyoUc.pgp Description: PGP signature
[devel-ref] author/homepage in description
I'd like to make a best practices note in the developers-reference about how to indicate the upstream author, author's email, and home page in the package description. I think this is would be a nice thing. Ideally debian/control's known fields would be extended, e.g., Upstream-Maintainer: John Doe [EMAIL PROTECTED] Upstream-Homepage: http://whatever.sourceforge.net/ Is this worthy of filing as a wishlist on dpkg? For now, I was planning on recommending something like this: We recommend that you add the upstream author's name, email address, and the URL for the package's homepage to the package description in debian/control. It should be added at the end of description, using the following format: . Author: Norman Walsh [EMAIL PROTECTED] Homepage: http://docbook.sourceforge.net/ Note the spaces prepending the line, which serves to break the lines correctly. To see an example of how this displays, see URL:http://packages.debian.org/unstable/text/docbook-dsssl.html. Note that noting the upstream author is irrelevant for Debian-only packages; some of these packages may have home pages, although few do. Comments desired. -- ...Adam Di Carlo..[EMAIL PROTECTED]...URL:http://www.onshored.com/
Re: [devel-ref] author/homepage in description
On Sun, Dec 08, 2002 at 05:08:20PM -0600, Adam DiCarlo wrote: Ideally debian/control's known fields would be extended, e.g., Upstream-Maintainer: John Doe [EMAIL PROTECTED] Upstream-Homepage: http://whatever.sourceforge.net/ Is this worthy of filing as a wishlist on dpkg? definitely. specialized tools could then process this. -- gram pgpl6l17G1aGa.pgp Description: PGP signature
Re: [devel-ref] author/homepage in description
On Sun, Dec 08, 2002 at 05:24:58PM -0600, Graham Wilson wrote: On Sun, Dec 08, 2002 at 05:08:20PM -0600, Adam DiCarlo wrote: Ideally debian/control's known fields would be extended, e.g., Upstream-Maintainer: John Doe [EMAIL PROTECTED] Upstream-Homepage: http://whatever.sourceforge.net/ Is this worthy of filing as a wishlist on dpkg? definitely. specialized tools could then process this. We could just use the existing support for user-defined fields for a while though. -- Colin Watson [EMAIL PROTECTED]
Re: [devel-ref] author/homepage in description
On 12/08/02 18:08, Adam DiCarlo wrote: Ideally debian/control's known fields would be extended, e.g., Upstream-Maintainer: John Doe [EMAIL PROTECTED] Upstream-Homepage: http://whatever.sourceforge.net/ Is this worthy of filing as a wishlist on dpkg? Personally, there have been many times that I saw a new package announced in DWN and I would click the link to packages.debian.org, read the package description, and want more information. So I would then go to Google and try to find the homepage. I would like to see a URI on the packages page where I could click for more information, get screenshots, etc. I really don't see much reason for an upstream maintainer, specifically, but a pointer to a mailing list or set of mailing lists (eg, there are several for GIMP) where I can search past archives or subscribe would be nice. For small projects, a single email may suffice, but this should be a URI for projects that may not have an email accessible gateway. I know of none offhand, but it just means to use a mailto: Joe [EMAIL PROTECTED] instead of expecting an email address, which solves the 'set of mailing lists' problem, presuming there is a page listing them. Upsteam-Support: may be a better name, therefore. I have also wanted to know from where the source was downloaded a few times - like which of the 8 versions of ghostscript did _this_ ghostscript package come from? if anything was taken out of CVS, and where did these patches come from? etc. Most of this information can usually be found by reading pages upon pages upon pages of terse entries in /usr/share/doc/* but not always, and I can almost never find what I'm looking for anyway. bah! All that being said, Upstream-Support: and Upstream-Homepage: would be very helpful for the rubes like me, especially with automated tools that pull these out and put them on webpages. ;-) . Author: Norman Walsh [EMAIL PROTECTED] Homepage: http://docbook.sourceforge.net/ Some packages already do this, and it is appreciated. For something so formally structured I think it should migrate into the header. Chris
Re: [devel-ref] author/homepage in description
Colin Watson [EMAIL PROTECTED] writes: We could just use the existing support for user-defined fields for a while though. Oh ! Where can I read about these? They aren't mentioned in deb-control(5) or /usr/share/doc/dpkg nor /usr/share/doc/dpkg-dev ... -- ...Adam Di Carlo..[EMAIL PROTECTED]...URL:http://www.onshored.com/
Re: [devel-ref] author/homepage in description
Christopher W. Curtis [EMAIL PROTECTED] writes: I really don't see much reason for an upstream maintainer, Yes, there's been a lot of good arguments for not bothering with the maintainer name. You can get that from the pkg home page tho... specifically, but a pointer to a mailing list or set of mailing lists (eg, there are several for GIMP) where I can search past archives or subscribe would be nice. I think this is subsumed in home page. I have also wanted to know from where the source was downloaded a few times This is by policy always in /usr/share/doc/pkg/copyright. -- ...Adam Di Carlo..[EMAIL PROTECTED]...URL:http://www.onshored.com/
