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
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
de
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: p
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
> gener
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
On Mon, Dec 16, 2002 at 05:06:55PM +0100, Wichert Akkerman wrote:
> 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.
And the same amount of data they'll get anyway, just from regular
devel
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 th
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
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 curr
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
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 exepec
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?
>
> W
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 w
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 exist
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 releva
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?
On Sun, Dec 15, 2002 at 11:37:56AM +0100, Wichert Akkerman wrote:
> > Scenario: we start using XK- now, then wait for it to become common
> > practice, dpkg gets changed to support , all those packages that have
> > XK- need another change to s/XK-//.
>
> Not necessarily need, the XK field would s
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.
--
Previously Josip Rodin wrote:
> Scenario: we start using XK- now, then wait for it to become common
> practice, dpkg gets changed to support , all those packages that have
> XK- need another change to s/XK-//.
Not necessarily need, the XK field would still work but there would just
be a new prefer
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 slo
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:
> >
> >
>
> 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.
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)
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]>...http://www.onshored.com/>
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 suppo
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 pag
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 th
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
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 pack
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
>
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 abo
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
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
[E
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 o
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
> [...]
>
>
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 e
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.pat
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:
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
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
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 ap
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
[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.
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.)
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
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+ mont
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.
-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 fie
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.
>
> Scen
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.o
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
On Mon, 9 Dec 2002, Joey Hess wrote:
> 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 fil
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 t
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 "developme
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 i
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- now, then wait for it to becom
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//
could point to CVS files instead of released ones. And as
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
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,
[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 woul
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
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 maintai
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 home
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 th
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 ar
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/d
"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 o
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 PROTEC
On Sun, Dec 08, 2002 at 05:08:20PM -0600, Adam DiCarlo wrote:
> 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 sh
On Sun, Dec 08, 2002 at 05:08:20PM -0600, Adam DiCarlo wrote:
> 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
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 t
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.sou
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?
def
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:
73 matches
Mail list logo
