[Emilio Pozuelo Monfort]
> We haven't agreed on whether there should be one ddeb per source or
> per binary package, so I would leave this still opened.
Maybe I'm losing track of things here, but it seems to me that everyone
except you is saying one ddeb per binary. And then you say "sure, we
co
Emilio Pozuelo Monfort writes:
> Russ Allbery wrote:
>> https://wiki.ubuntu.com/AptElfDebugSymbols is the specification. It
>> does use *.ddeb. There isn't any clear statement about how *.ddeb
>> packages differ from *.deb packages. It looks like, by and large, they
>> don't, except they may n
Philipp Kern writes:
> And I have to agree with Emilio that I don't see the point of a 1:1
> relationship of ddeb to binary package just for the sake of library
> transitions. I wonder if we could just unpack the debugging build-id
> objects to some other location than globally and point gdb to
Russ Allbery wrote:
> https://wiki.ubuntu.com/AptElfDebugSymbols is the specification. It does
> use *.ddeb. There isn't any clear statement about how *.ddeb packages
> differ from *.deb packages. It looks like, by and large, they don't,
> except they may not need to contain the same set of thin
Manoj Srivastava wrote:
> On Wed, Aug 12 2009, Emilio Pozuelo Monfort wrote:
>
>
>> There will still be a repository with all the .ddebs.
>
> And aptitude and dpkg will know how to install ddebs, somehow?
> and synaptic, etc?
Yes, dpkg, apt-get, aptitude and synaptic all work perfectly
On 2009-08-13, Manoj Srivastava wrote:
>> Ah, and it looks like the automated crash reporting offers to download the
>> -dbgsym packages and install them.
> Reading the spec, it seems to me that the primary motivation was
> for users to provide crash dumps with bug reports, and not much s
On Wed, Aug 12 2009, Russ Allbery wrote:
> Paul Wise writes:
>
>> Not having anything to do with Ubuntu, I don't know anything about the
>> details, but they have had automatic debug packages and automated
>> crash report stuff for quite a while, a couple of years II
On Wed, Aug 12 2009, Russ Allbery wrote:
> Paul Wise writes:
>> On Thu, Aug 13, 2009 at 10:10 AM, Manoj Srivastava
>> wrote:
>
>>> I too am wondering if we should defer the polivy change until
>>> the details get shaken out with a partial deployment of the scheme.
>
>> Full deployment al
Paul Wise writes:
> Not having anything to do with Ubuntu, I don't know anything about the
> details, but they have had automatic debug packages and automated
> crash report stuff for quite a while, a couple of years IIRC. The
> specs for that are here:
>
> https://launchp
On Wed, Aug 12 2009, Emilio Pozuelo Monfort wrote:
> There will still be a repository with all the .ddebs.
And aptitude and dpkg will know how to install ddebs, somehow?
and synaptic, etc?
> But also we will have a share that will ship all the debugging symbols
> in a build id file hie
Hi!
On Tue, 2009-08-11 at 13:03:13 -0700, Russ Allbery wrote:
> Open questions:
> * Can we require a one-to-one correspondance between binary package names
> and debug package names that provide symbols for that binary package? I
> think we should; I think it would make the system more strai
Russ Allbery wrote:
> Josselin Mouette writes:
>> If we use build IDs (and this has quite some advantages, like being able
>> to do more than just dump the ddebs on a repository), this can lead to
>> having the same detached debugging symbols in two binary packages, since
>> sometimes a binary is
Josselin Mouette writes:
> Le mardi 11 août 2009 à 17:26 -0700, Russ Allbery a écrit :
>> I don't understand how what you say is related to what I said. How
>> does having them in a separate archive affect whether or not I have to
>> download a 50GB package to get debugging symbols for KDE? Whe
Le mardi 11 août 2009 à 17:26 -0700, Russ Allbery a écrit :
> > The main purpose of setting up an archive of debugging symbols is to be
> > able to use them transparently without installation, so that doesn’t
> > change much.
>
> I don't understand how what you say is related to what I said. How
Josselin Mouette writes:
> Le mardi 11 août 2009 à 16:13 -0700, Russ Allbery a écrit :
>> Without the symlink, they're not valid Debian packages. It seems like
>> a small price to pay for keeping them consistent with the rest of
>> Policy.
> The policy is just a document. The question is more a
Manoj Srivastava writes:
> So policy is going to prohibit contrib or non-free packages
> with debugging symbols (or, at least, debug packages that may use the
> common nomenclature)? This seems kinda drastic. So the packages with
> debug symbols from those sources will continue to liv
Le mardi 11 août 2009 à 16:13 -0700, Russ Allbery a écrit :
> > Actually I don’t see the point in this symlink. It only makes things
> > more complicated, especially if there is no one-to-one mapping between
> > ddebs and debs.
>
> Without the symlink, they're not valid Debian packages. It seems
On Tue, Aug 11 2009, Russ Allbery wrote:
> Josselin Mouette writes:
>> Le mardi 11 août 2009 à 13:03 -0700, Russ Allbery a écrit :
>>> * What about contrib and non-free packages? Do they just lose here?
>
>> How about yes?
>
> I'm okay with that as an answer. I just want to document it if so.
Josselin Mouette writes:
> Le mardi 11 août 2009 à 13:03 -0700, Russ Allbery a écrit :
>> * These packages are normal Debian packages with normal package metadata,
>> but will generally have a symlink in /usr/share/doc/ pointing
>> to the package for which they provide debugging information.
Le mardi 11 août 2009 à 13:03 -0700, Russ Allbery a écrit :
> * These packages are normal Debian packages with normal package metadata,
> but will generally have a symlink in /usr/share/doc/ pointing
> to the package for which they provide debugging information.
Actually I don’t see the point
Philipp Kern writes:
> On 2009-08-11, Russ Allbery wrote:
>>> If it's legal to ship debugging symbols for them, I can't see why we
>>> couldn't support them normally.
>> The point is that you can't do this with an archive area, at least
>> using the simple algorithm I proposed above.
> Well yo
["Followup-To:" header set to gmane.linux.debian.devel.general.]
On 2009-08-11, Russ Allbery wrote:
>> If it's legal to ship debugging symbols for them, I can't see why we
>> couldn't support them normally.
> The point is that you can't do this with an archive area, at least using
> the simple alg
Russ Allbery wrote:
> Emilio Pozuelo Monfort writes:
>
>> You can build a .ddeb manually, yes. However for some cases
>> (e.g. packages using debhelper and building ELF binaries) a .ddeb will
>> be automatically created (if none is created manually) and detached
>> debugging symbols will be put t
Emilio Pozuelo Monfort writes:
> Russ Allbery wrote:
>> * These packages are normal Debian packages with normal package metadata,
>> but will generally have a symlink in /usr/share/doc/ pointing
>> to the package for which they provide debugging information.
> We haven't agreed on whether th
Russ Allbery wrote:
> Emilio Pozuelo Monfort writes:
>> Russ Allbery wrote:
>
>>> It sounds like listing them only in *.changes but not in *.dsc or
>>> debian/control may be the easiest approach.
>> Indeed, for the automatic-not-listed-in-debian-control ones. The others
>> would be listed everywh
Emilio Pozuelo Monfort writes:
> Russ Allbery wrote:
>> It sounds like listing them only in *.changes but not in *.dsc or
>> debian/control may be the easiest approach.
>
> Indeed, for the automatic-not-listed-in-debian-control ones. The others
> would be listed everywhere, but that is okay.
Yes
Russ Allbery wrote:
>> Having them in the Binary section in the .dsc and Binary and Description
>> in the .changes files would mean modifying
>> dpkg-buildpackage/dpkg-genchanges for ddebs not listed in
>> debian/control. However listing them in Files and Checksum-* in the
>> .changes requires no c
On Tue, Aug 11 2009, Steve Langasek wrote:
> But if this is all the more respect you have for your fellow (TC
> members|DDs|human beings), O Peerless and Saintly Policy Editor, then
> perhaps the project should reconsider whether that's a position you should
> hold.
The -vote list is ->
Emilio Pozuelo Monfort writes:
> Manoj Srivastava wrote:
>> So I think at this point it is premature for policy to decide
>> one way or the other about debug symbol packages being mentioned in
>> the control file (and dsc and changes).
> They should be in the changes file so they are u
Manoj Srivastava wrote:
> On Tue, Aug 11 2009, Russ Allbery wrote:
>
>> Emilio Pozuelo Monfort writes:
>>> Manoj Srivastava wrote:
To recap:
1) packages with detached debugging symbols should be named
${package name}-${debug suffix}. As a corollary, no ordinary
On Tue, Aug 11, 2009 at 01:50:21PM -0500, Gunnar Wolf wrote:
> > I don't have a strong opinion on whether ddebs should be documented in
> > policy, but I certainly don't agree with requiring dpkg to understand them
> > as a prerequisite for implementing a general purpose, public archive for
> > au
On Mon, Aug 10, 2009 at 06:06:37PM -0500, Manoj Srivastava wrote:
> >> So, please keep heckling from the peanut gallery to a minimum,
> >> please, and assume that policy editors have a modicum of sense when
> >> dealing with their role duties.
> > If you were showing a modicum of sense,
On Tue, Aug 11, 2009 at 2:45 PM, Gunnar Wolf wrote:
> Russ Allbery dijo [Sat, Aug 08, 2009 at 05:51:33PM -0700]:
>> > You can build a .ddeb manually, yes. However for some cases
>> > (e.g. packages using debhelper and building ELF binaries) a .ddeb will
>> > be automatically created (if none is cre
Steve Langasek dijo [Sun, Aug 09, 2009 at 05:15:39PM -0700]:
> > If we are going to enshrine ddebs into policy, we might as well
> > teach dpkg about ddebs.
>
> I don't have a strong opinion on whether ddebs should be documented in
> policy, but I certainly don't agree with requiring dpkg
Russ Allbery dijo [Sat, Aug 08, 2009 at 05:51:33PM -0700]:
> > You can build a .ddeb manually, yes. However for some cases
> > (e.g. packages using debhelper and building ELF binaries) a .ddeb will
> > be automatically created (if none is created manually) and detached
> > debugging symbols will be
On Tue, Aug 11 2009, Russ Allbery wrote:
> Emilio Pozuelo Monfort writes:
>> Manoj Srivastava wrote:
>
>>> To recap:
>>> 1) packages with detached debugging symbols should be named
>>> ${package name}-${debug suffix}. As a corollary, no ordinary
>>> packages names may end in ${d
Emilio Pozuelo Monfort writes:
> Manoj Srivastava wrote:
>> To recap:
>> 1) packages with detached debugging symbols should be named
>> ${package name}-${debug suffix}. As a corollary, no ordinary
>> packages names may end in ${debug suffix}.
> They may be automatically created
Manoj Srivastava wrote:
> On Tue, Aug 11 2009, Emilio Pozuelo Monfort wrote:
>> Manoj Srivastava wrote:
>>> Can you point ot me the disadvantage of continuing to use what
>>> dh_strip does now?
>> It can still be used, but you will miss the advantages of using build ids.
>
> I gu
On Tue, Aug 11 2009, Emilio Pozuelo Monfort wrote:
> Manoj Srivastava wrote:
>
>> OK, I guess that would work. But you still have the advantage,
>> using the current debug link mechanism, of looking to see if you have
>> debug symbols for a given executable/library easily, without havin
On Mon, Aug 10, 2009 at 03:59:22PM -0700, Steve Langasek wrote:
> On Mon, Aug 10, 2009 at 09:46:49PM +0100, Roger Leigh wrote:
> > Reading through this thread, I don't see a compelling reason for using
> > a .ddeb extension given that they are just regular .debs, nor for
> > keeping the packages se
On Tue, Aug 11, 2009 at 18:37:05 +0200, Emilio Pozuelo Monfort wrote:
> Manoj Srivastava wrote:
> > 2) These packages may just symlink
> > /usr/share/doc/${package name}-${debug suffix} to
> > /usr/share/doc/${package name}
> > (and of course, depend on ${package name}
>
> 5) There m
Manoj Srivastava wrote:
> Hi,
>
> All right. Having been educated about the new build-id
> mechanism, I think there is not reason for policy to prohibit either
> approach, or to settle on one or the other.
>
> To recap:
> 1) packages with detached debugging symbols should be na
Manoj Srivastava wrote:
> On Tue, Aug 11 2009, Josselin Mouette wrote:
>
>> Le mardi 11 août 2009 à 10:11 -0500, Manoj Srivastava a écrit :
>>> Except you have not indicated how you (or debhelper) is going to
>>> intercept ld to add the requisite arguments.
>> http://lists.debian.org/debi
Hi,
All right. Having been educated about the new build-id
mechanism, I think there is not reason for policy to prohibit either
approach, or to settle on one or the other.
To recap:
1) packages with detached debugging symbols should be named
${package name}-${debug suffix}.
On Tue, Aug 11 2009, Josselin Mouette wrote:
> Le mardi 11 août 2009 à 10:11 -0500, Manoj Srivastava a écrit :
>> Except you have not indicated how you (or debhelper) is going to
>> intercept ld to add the requisite arguments.
>
> http://lists.debian.org/debian-devel-changes/2009/07/msg01
Manoj Srivastava wrote:
> On Tue, Aug 11 2009, Josselin Mouette wrote:
>
>> Le mardi 11 août 2009 à 08:24 -0500, Manoj Srivastava a écrit :
>>> Hmm. I see very little benefit here. Firstly, to use build id,
>>> you have to intercept the upstream build system and add --build-id
>>> (and p
Le mardi 11 août 2009 à 10:39 -0500, Manoj Srivastava a écrit :
> However, if you do not use the build-id mechanism, and use what
> we currently use in dh_strip and friends, objcopy --add-gnu-debuglink
> adds information that gdb looks at to figure out where the debug
> symbols live -- a
Josselin Mouette wrote:
> Le mardi 11 août 2009 à 10:11 -0500, Manoj Srivastava a écrit :
>> Except you have not indicated how you (or debhelper) is going to
>> intercept ld to add the requisite arguments.
>
> http://lists.debian.org/debian-devel-changes/2009/07/msg01229.html
Also see ht
On Tue, Aug 11 2009, Josselin Mouette wrote:
> Le mardi 11 août 2009 à 08:24 -0500, Manoj Srivastava a écrit :
>> Hmm. I see very little benefit here. Firstly, to use build id,
>> you have to intercept the upstream build system and add --build-id
>> (and perhaps the --build-id-style) opt
Steve Langasek wrote:
> On Mon, Aug 10, 2009 at 09:46:49PM +0100, Roger Leigh wrote:
>> Reading through this thread, I don't see a compelling reason for using
>> a .ddeb extension given that they are just regular .debs, nor for
>> keeping the packages separate from the main archive (if the size of
Le mardi 11 août 2009 à 10:11 -0500, Manoj Srivastava a écrit :
> Except you have not indicated how you (or debhelper) is going to
> intercept ld to add the requisite arguments.
http://lists.debian.org/debian-devel-changes/2009/07/msg01229.html
--
.''`. Josselin Mouette
: :' :
`.
On Tue, Aug 11 2009, Sune Vuorela wrote:
> On 2009-08-11, Manoj Srivastava wrote:
>> Hmm. I see very little benefit here. Firstly, to use build id,
>> you have to intercept the upstream build system and add --build-id
>> (and perhaps the --build-id-style) option to ld, instead of the cu
Le mardi 11 août 2009 à 08:24 -0500, Manoj Srivastava a écrit :
> Hmm. I see very little benefit here. Firstly, to use build id,
> you have to intercept the upstream build system and add --build-id
> (and perhaps the --build-id-style) option to ld, instead of the current
> method of lett
On Tue, Aug 11, 2009 at 01:40:20PM +, Sune Vuorela wrote:
> On 2009-08-11, Manoj Srivastava wrote:
> > So, we would still need to create "/usr/lib/debug/"
> > . /full/path/to/lib_or_binary/ in either case, and instead of the
>
> no. it would be /usr/lib/debug/.build-id/NN/NN.de
On 2009-08-11, Manoj Srivastava wrote:
> Hmm. I see very little benefit here. Firstly, to use build id,
> you have to intercept the upstream build system and add --build-id
> (and perhaps the --build-id-style) option to ld, instead of the current
> method of letting the upstream build h
On Tue, Aug 11 2009, Sune Vuorela wrote:
> On 2009-08-10, Manoj Srivastava wrote:
>> On Mon, Aug 10 2009, Sune Vuorela wrote:
>>
>>> On 2009-08-10, Manoj Srivastava wrote:
I would also add that the debug symbols should live in
"/usr/lib/debug/" . /full/path/to/lib_or_binary, b
On 2009-08-10, Manoj Srivastava wrote:
> On Mon, Aug 10 2009, Sune Vuorela wrote:
>
>> On 2009-08-10, Manoj Srivastava wrote:
>>> I would also add that the debug symbols should live in
>>> "/usr/lib/debug/" . /full/path/to/lib_or_binary, blessing the current
>>> practice.
>>
>> You are
On Mon, Aug 10 2009, Steve Langasek wrote:
> On Mon, Aug 10, 2009 at 11:17:45AM -0500, Manoj Srivastava wrote:
>> > There is a namespace issue here, that falls in scope for Policy because it
>> > impacts interoperability; if there are going to be limits placed on the
>> > names of packages in the
On Mon, Aug 10 2009, Sune Vuorela wrote:
> On 2009-08-10, Manoj Srivastava wrote:
>> I would also add that the debug symbols should live in
>> "/usr/lib/debug/" . /full/path/to/lib_or_binary, blessing the current
>> practice.
>
> You are missing the new features of build-id as written e
On Mon, Aug 10, 2009 at 09:46:49PM +0100, Roger Leigh wrote:
> Reading through this thread, I don't see a compelling reason for using
> a .ddeb extension given that they are just regular .debs, nor for
> keeping the packages separate from the main archive (if the size of the
> Packages file is an i
On Mon, Aug 10, 2009 at 11:20:17AM -0500, Manoj Srivastava wrote:
> >> Or even just -dbg, since aren't the existing debug packages basically
> >> .ddebs, modulo bugs?
> > There are a few significant exceptions, such as libc6-dbg and libqt4-dbg,
> > where the packages contain complete alternate deb
On Mon, Aug 10, 2009 at 11:17:45AM -0500, Manoj Srivastava wrote:
> > There is a namespace issue here, that falls in scope for Policy because it
> > impacts interoperability; if there are going to be limits placed on the
> > names of packages in the main archive, that almost certainly *does* belong
Stephen Gran writes:
> The only reason I can see for an extension like .ddeb is that it would
> signal that they're like more like .udebs than .debs (not for regular
> user consumption, may not have all the files under /usr/share/doc, may
> have some funky layout based on this build-id idea, what
This one time, at band camp, Manoj Srivastava said:
> On Mon, Aug 10 2009, Roger Leigh wrote:
>
> > Could we not just use a "-ddbg" suffix for "detached debug" information,
> > perhaps with a new archive section to match? This will not conflict
> > with existing practice for -dbg, so could go int
On 2009-08-10, Manoj Srivastava wrote:
> I would also add that the debug symbols should live in
> "/usr/lib/debug/" . /full/path/to/lib_or_binary, blessing the current
> practice.
You are missing the new features of build-id as written earlier by
insisting on this.
/Sune
--
To UNSUB
On 2009-08-10, Roger Leigh wrote:
> That's what I meant (just not sure of the correct dak terminology).
> Would this present problems for the ftp-masters, since TTBOMK currently
> source and binary packages are restricted to the same area? i.e. would
> work on projectb/dak be required to implemen
On Mon, Aug 10 2009, Roger Leigh wrote:
> Could we not just use a "-ddbg" suffix for "detached debug" information,
> perhaps with a new archive section to match? This will not conflict
> with existing practice for -dbg, so could go into Policy without
> violating any prexisting namespace conventi
On Mon, Aug 10 2009, Don Armstrong wrote:
>> Also, It is indeed trivial to add that to non-helper-package using
>> packages, it just requires some editing (just like modufying helper
>> packages will need editing).
>
> Since it's trivial, I look forward to seeing patches from you to
> implement p
On Mon, Aug 10, 2009 at 01:55:51PM -0700, Russ Allbery wrote:
> Roger Leigh writes:
>
> > nor for keeping the packages separate from the main archive (if the size
> > of the Packages file is an issue, can't they just go in a separate debug
> > section/component?)
>
> The Packages file lists all
Roger Leigh writes:
> On Mon, Aug 10, 2009 at 07:52:23AM -0700, Steve Langasek wrote:
>> On Sun, Aug 09, 2009 at 05:42:04PM -0700, Russ Allbery wrote:
>>> Or even just -dbg, since aren't the existing debug packages basically
>>> .ddebs, modulo bugs?
>> There are a few significant exceptions, suc
On Mon, Aug 10, 2009 at 07:52:23AM -0700, Steve Langasek wrote:
> On Sun, Aug 09, 2009 at 05:42:04PM -0700, Russ Allbery wrote:
> > > I don't have a strong opinion on whether ddebs should be documented in
> > > policy, but I certainly don't agree with requiring dpkg to understand
> > > them as a pr
On Mon, 10 Aug 2009, Manoj Srivastava wrote:
> On Mon, Aug 10 2009, Don Armstrong wrote:
> > On Mon, 10 Aug 2009, Manoj Srivastava wrote:
> >> Why is it not trivial?
> >
> > Because it requires editing the rules file for each such package?
> > (debhelper using packages all get tweaked in a single
On Mon, Aug 10 2009, Don Armstrong wrote:
> On Mon, 10 Aug 2009, Manoj Srivastava wrote:
>> Why is it not trivial?
>
> Because it requires editing the rules file for each such package?
> (debhelper using packages all get tweaked in a single shot.)
Rubbish. I suspect all cdbs using packa
On Mon, Aug 10 2009, Philipp Kern wrote:
>> Why is it not trivial? I have such a hook in my pakages, and it
>> is not rocket science.
>>
>> If you think that adding stuff like
>> --8<---cut here---start->8---
>> file
On Mon, 10 Aug 2009, Manoj Srivastava wrote:
> Why is it not trivial?
Because it requires editing the rules file for each such package?
(debhelper using packages all get tweaked in a single shot.)
Don Armstrong
--
All my dreams came true.
I just didn't think them through.
-- a softer world #
On Mon, Aug 10 2009, Steve Langasek wrote:
> On Sun, Aug 09, 2009 at 07:37:10PM -0500, Manoj Srivastava wrote:
>
>> >> > dpkg doesn't know about filenames AFAICS. So you can't coinstall
>> >> > foo_1.0-1_i386.deb and foo_1.0-1_i386.ddeb, right? So we do want the
>> >> > -ddeb suffix.
>
>> >>
On Mon, Aug 10 2009, Steve Langasek wrote:
> On Sun, Aug 09, 2009 at 05:42:04PM -0700, Russ Allbery wrote:
>> > I don't have a strong opinion on whether ddebs should be documented in
>> > policy, but I certainly don't agree with requiring dpkg to understand
>> > them as a prerequisite for implemen
On 2009-08-10, Manoj Srivastava wrote:
>> Most -dbg packages *shouldn't* live in the archive, but maintainers
>> keep adding them by hand anyway, and we don't have anywhere else to
>> put them.
> Well, right now there is nowhere to put the .ddebs either, and
> they are really just .debs w
On Mon, Aug 10 2009, Steve Langasek wrote:
> On Mon, Aug 10, 2009 at 06:48:47AM -0500, Manoj Srivastava wrote:
>> > The main point is probably that they shouldn't live in the main
>> > archive due to space reasons. Of course we could also filter out
>> > '*-ddeb*' or '*-dbgsym*' as long as it's n
On Sun, Aug 09, 2009 at 05:42:04PM -0700, Russ Allbery wrote:
> > I don't have a strong opinion on whether ddebs should be documented in
> > policy, but I certainly don't agree with requiring dpkg to understand
> > them as a prerequisite for implementing a general purpose, public
> > archive for au
On Mon, Aug 10, 2009 at 06:48:47AM -0500, Manoj Srivastava wrote:
> > The main point is probably that they shouldn't live in the main
> > archive due to space reasons. Of course we could also filter out
> > '*-ddeb*' or '*-dbgsym*' as long as it's not '*-dbg*', which should be
> If automa
On Sun, Aug 09, 2009 at 07:37:10PM -0500, Manoj Srivastava wrote:
> >> > dpkg doesn't know about filenames AFAICS. So you can't coinstall
> >> > foo_1.0-1_i386.deb and foo_1.0-1_i386.ddeb, right? So we do want the
> >> > -ddeb suffix.
> >> If we are going to enshrine ddebs into policy, w
On Mon, Aug 10 2009, Philipp Kern wrote:
> On 2009-08-10, Manoj Srivastava wrote:
>>> dpkg "knows" about them the same way it "knows" about debs, AFAICS.
>> Why, then, the .ddeb suffix? Why are these not just .debs, with
>> a specific naming schema?
>
> At least they shouldn't clash with
On 2009-08-10, Manoj Srivastava wrote:
>> dpkg "knows" about them the same way it "knows" about debs, AFAICS.
> Why, then, the .ddeb suffix? Why are these not just .debs, with
> a specific naming schema?
At least they shouldn't clash with maintainer-defined ones, IMHO, as they
are create
On Sun, Aug 09 2009, Steve Langasek wrote:
> On Sat, Aug 08, 2009 at 08:33:09PM -0500, Manoj Srivastava wrote:
>> > Manoj Srivastava wrote:
>> >> On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
>> >>> I've documented the .ddeb format in the wiki page [1] ("DDeb Format",
>> >>> which is short si
Steve Langasek writes:
> I don't have a strong opinion on whether ddebs should be documented in
> policy, but I certainly don't agree with requiring dpkg to understand
> them as a prerequisite for implementing a general purpose, public
> archive for auto-stripped debugging symbols packages. Ther
On Sat, Aug 08, 2009 at 08:33:09PM -0500, Manoj Srivastava wrote:
> > Manoj Srivastava wrote:
> >> On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
> >>> I've documented the .ddeb format in the wiki page [1] ("DDeb Format",
> >>> which is short since the format is basically that of .debs). Do we
Hi,
On Sonntag, 9. August 2009, Manoj Srivastava wrote:
> The link to the wiki page was missing
> http://wiki.debian.org/AutomaticDebugPackages
this link was also missing in #508585.
regards,
Holger
signature.asc
Description: This is a digitally signed message part.
Manoj Srivastava writes:
> On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
>
>> Manoj Srivastava wrote:
>>> On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
I've documented the .ddeb format in the wiki page [1] ("DDeb Format",
which is short since the format is basically that of .d
On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
> Manoj Srivastava wrote:
>> On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
>>> I've documented the .ddeb format in the wiki page [1] ("DDeb Format",
>>> which is short since the format is basically that of .debs). Do we
>>> really need this t
Emilio Pozuelo Monfort writes:
> You can build a .ddeb manually, yes. However for some cases
> (e.g. packages using debhelper and building ELF binaries) a .ddeb will
> be automatically created (if none is created manually) and detached
> debugging symbols will be put there. I'll try to automatize
Manoj Srivastava wrote:
> On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
>> I've documented the .ddeb format in the wiki page [1] ("DDeb Format",
>> which is short since the format is basically that of .debs). Do we
>> really need this to be documented in policy?
>
> Not if that is all
On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
> [ Moving to debian-policy ]
>
> Manoj Srivastava wrote:
>> On Fri, Jul 31 2009, Emilio Pozuelo Monfort wrote:
>>
>>> Manoj Srivastava wrote:
We do not want to have different helper package start inventing
a helper specific wa
[ Moving to debian-policy ]
Manoj Srivastava wrote:
> On Fri, Jul 31 2009, Emilio Pozuelo Monfort wrote:
>
>> Manoj Srivastava wrote:
>>> We do not want to have different helper package start inventing
>>> a helper specific way of building ddebs, with no clear standard tha
>>> they are
94 matches
Mail list logo
