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

Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)



On Sat, Apr 04, 2015 at 10:54:09AM +0200, Niels Thykier wrote:
> The resulting debs are installable with dpkg -i ( \o/ ).  I have not
> tried anything fancy like setting up a local APT mirror and tried to
> convince APT do install it.

I did and apt works with ddeb just fine, meaning it can happily
print infos about them, download them and install them with dpkg.

There are two exceptions as far as I can see:
- apt-ftparchive doesn't know about '.ddeb', so by default neither
  Contents nor Packages files created by it contain information about
  them. Users of "apt-ftparchive contents/packages" are (surprisingly)
  out of luck as far as I can see and have to wait for a patch (= 2
  lines), but users of "apt-ftparchive generate" can configure the used
  extension, see apt-ftparchive manpage on how to do that.

  Debian uses dak to create the archive, so that isn't a problem per-se.
  I would presume most derivatives aren't using it either as
  alternatives are plenty.  Those who do are very likely using generate
  as its just strictly better than manually creating Packages files with
  'apt-ftparchive packages'. I guess most repository creators have this
  or similar problems and solutions through and that doesn't seem like
  all to important for the adoption.

- apt/experimental supports installing local .deb files. That doesn't
  support the '.ddeb' extension yet.

  I leave it up to the reader to figure out how much of a dealbreaker
  that is…


So, super-cow approves (d)debs.
(In fact, apt-dbg never became a thing as automatic ddebs were always
 "very soon now" in existence every time it came up. This time please…)
And it especially approves the debhelper branch name. ;)


I think there will be some work upon us to make ddebs supported well
(I invision something like a "apt-get debugsymbols foo" which installs
the package foo-dbgsym and maybe optionally also the debug packages of
the direct dependencies libfoo1 (libfoo-dbgsym) and libbar0.1
(python3-bar-dbgsym as it is the c-binding of a python library as you
might (not) have guessed).) but lets get them first, shall we? :)


btw: Is it planed to drop them into their own repository/component or
are we gone blow up our regular Packages files with them? (you might
guess from the wording which way I would prefer).


Best regards

David Kalnischkies

Attachment: signature.asc
Description: Digital signature


Reply to: