On 2009-08-10, Manoj Srivastava <sriva...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
