On Fri, 2009-11-27 at 12:09 +0800, Paul Wise wrote:
> It might actually be best to store all this upstream data in the
> PackageMap or somewhere associated with it and map from Debian package
> -> PackageMap name -> upstream metadata.
>
> I'm also reminded of things like DOAP, which are sometime
Le Fri, Nov 27, 2009 at 12:09:47PM +0800, Paul Wise a écrit :
> On Fri, Nov 27, 2009 at 12:03 PM, Charles Plessy wrote:
>
> > Again, all of this is very preliminary and undocumented. The main message I
> > would like to give is that indeed, for all the information that is not
> > specific
> > to
Jonathan Wiltshire writes:
> On Fri, Nov 27, 2009 at 11:50:30AM +1100, Ben Finney wrote:
>> Rather, it would be good to have a facility similar to the way the
>> Debian changelog is currently available: have the upstream changelog
>> published in a predictable location by package name.
> Where t
Jonathan Wiltshire writes:
> On Fri, Nov 27, 2009 at 11:50:30AM +1100, Ben Finney wrote:
> > Rather, it would be good to have a facility similar to the way the
> > Debian changelog is currently available: have the upstream changelog
> > published in a predictable location by package name.
>
> Whe
On Fri, Nov 27, 2009 at 4:55 PM, Jonathan Wiltshire
wrote:
> Where the changelog is already part of the source package and has a
> sensible name, and the package calls dh_installchangelogs, it's already
> installed as /usr/share/doc/*/changelog and the Debian changelog as
> changelog.Debian. The
On Fri, Nov 27, 2009 at 11:50:30AM +1100, Ben Finney wrote:
> Rather, it would be good to have a facility similar to the way the
> Debian changelog is currently available: have the upstream changelog
> published in a predictable location by package name.
Where the changelog is already part of the
On Fri, Nov 27, 2009 at 12:03 PM, Charles Plessy wrote:
> Again, all of this is very preliminary and undocumented. The main message I
> would like to give is that indeed, for all the information that is not
> specific
> to Debian, there must be other ways to make them flow from the maintainer to
Le Fri, Nov 27, 2009 at 11:06:51AM +0800, Paul Wise a écrit :
> On Fri, Nov 27, 2009 at 9:39 AM, Charles Plessy wrote:
>
> > I propose to store this information and similar ones in a parsable file in
> > the
> > debian directory of the packages. For instance,
> > debian/upstream-metadata.yaml.
Ben Finney wrote:
> This is what I do. Rationale: The Debian changelog, unlike the upstream
> changelog, is available for all Debian packages using standard tools
> *before* installing the package, which as a user is the time I most want
> to see what has changed in a new release of a package.
>
>
On Fri, Nov 27, 2009 at 9:39 AM, Charles Plessy wrote:
> I propose to store this information and similar ones in a parsable file in the
> debian directory of the packages. For instance, debian/upstream-metadata.yaml.
> For packages stored in a VCS, this information will be easy to retreive. The
>
Le Fri, Nov 27, 2009 at 11:50:30AM +1100, Ben Finney a écrit :
>
> Rather, it would be good to have a facility similar to the way the
> Debian changelog is currently available: have the upstream changelog
> published in a predictable location by package name.
>
> A good project from someone with
Tony Houghton writes:
> Good point. Is there not a control field where you can give a URL for
> an upstream changelog?
No, I don't think such a thing belongs in the ‘control’ file. There is
significant pressure *against* adding fields to that file, since the
addition of such a field bloats the r
On Fri, 27 Nov 2009 10:35:34 +1100
Ben Finney wrote:
> Tony Houghton writes:
>
> > What should go in a Debian changelog compared to the upstream
> > changelog?
>
> Well now, there's “should” and there's “should”.
>
> > (a) Confine it to "new upstream release", a list of any closed debian
> >
Tony Houghton writes:
> What should go in a Debian changelog compared to the upstream
> changelog?
Well now, there's “should” and there's “should”.
> (a) Confine it to "new upstream release", a list of any closed debian
> bugs and packaging changes?
Of the options you present, this seems the b
On Thu, Nov 26, 2009 at 10:29:31PM +, Tony Houghton wrote:
> What should go in a Debian changelog compared to the upstream changelog?
>
> (a) Confine it to "new upstream release", a list of any closed debian
> bugs and packaging changes?
Keep it to a minimum (that's what upstream's changelog
On Thu, Nov 26, 2009 at 10:29:31PM +, Tony Houghton wrote:
> What should go in a Debian changelog compared to the upstream changelog?
>
> (a) Confine it to "new upstream release", a list of any closed debian
> bugs and packaging changes?
>
> (b) As above plus a summary of the most important u
What should go in a Debian changelog compared to the upstream changelog?
(a) Confine it to "new upstream release", a list of any closed debian
bugs and packaging changes?
(b) As above plus a summary of the most important upstream changes?
(c) Details of all the upstream changes too?
--
TH * ht
17 matches
Mail list logo
