[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Automatic Debug Packages



On 2009-08-10, Manoj Srivastava <srivasta@debian.org> 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 with a funny name too. Not very different. 

I agree that we do not really need the .ddeb extension as we need to
avoid clashes in the package namespace anyway, with the extension not
helping us with that.

>> I'm not sure we would ever want to take packages that are
>> referenced in the source debian/control and move them to the separate
>> debug archive, I think that would play havoc with database
>> consistency.  It also gives us no clear way to tag files referenced in
>> a .changes file as belonging to the debug archive *except* for the
>> package name, and there are certainly -dbg packages that intentionally
>> contain things other than detached debugging symbols and which should
>> not be grouped with the ddebs.
>         How is a .ddeb package going to change things by the time it
>  gets into the archive? .ddebs will be there in the .changes file, and
>  the only way they are different is in the file name.

I'd guess we could also invent another section or priority for it if we want
to.  (But we didn't rely on such provided data yet, the authoriative data
always comes from the override database.)

>> The other end is that we need a usable hook for detaching the symbols
>> instead of discarding them, which is trivial for all debhelper-using
>> packages, and not at all trivial for packages not using debhelper.
>
>         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                            lib_or_exec_file
>  objcopy --only-keep-debug       lib_or_exec_file  debug_file
>  objcopy ----add-gnu-debuglink   debug_file lib_or_exec_file
>
>  strip --remove-section=.comment --remove-section=.note \
>     --strip-unneeded lib_file
>  strip  --remove-section=.comment --remove-section=.note exec_file
> --8<---------------cut here---------------end--------------->8---
>
>  to a rules file is "not at all trivial", then heaven help us.

Plus lines to actually create the package with appropriate control info
or/and putting it into debian/control which we wanted to avoid (I think).

Of course if we then go and try to modify the behaviour slightly (like
having build-ids and stuff) we still have to modify all those packages
and not just the helper and a binNMU.  But I guess I can't argue with
you about that anyway.  From a policy PoV you're right, we do not
impose debhelper upon everyone.

I already consider debhelper coverage as a worthy goal.  :-P

Kind regards,
Philipp Kern


Reply to: