ip link tool has an ability to use external shared libraries for
defining custom device kinds which will be managed by the tool.
To build such libraries three header files are needed. It would
be great to provide this headers in a dev package.
---
From: Evgenii Smirnov <evgenii.smirnov@profitbricks.com>
Date: Mon, 11 Dec 2017 19:01:44 +0100
Subject: [PATCH] Add iproute2-dev package

The package provides necessary header files for building
extention static libraries for ip link tool. Libraries allow
user to define his own device kinds that will be managed by ip link.

Signed-off-by: Evgenii Smirnov <evgenii.smirnov@profitbricks.com>
---
 debian/control              | 11 +++++++++++
 debian/iproute2-dev.install |  3 +++
 2 files changed, 14 insertions(+)
 create mode 100644 debian/iproute2-dev.install

diff --git a/debian/control b/debian/control
index b98fbe8..2a13005 100644
--- a/debian/control
+++ b/debian/control
@@ -43,6 +43,17 @@ Description: networking and traffic control tools
  interface, providing advanced features not available through the
  legacy net-tools commands 'ifconfig' and 'route'.

+Package: iproute2-dev
+Section: libdevel
+Architecture: any
+Depends: ${misc:Depends}
+Description: networking and traffic control tools - development files
+ The iproute suite, also known as iproute2, is a collection of
+ utilities for networking and traffic control.
+ .
+ This package contains the header files for
+ compiling iproute link kind extensions, and is needed only for
development.
+
 Package: iproute2-doc
 Section: doc
 Architecture: all
diff --git a/debian/iproute2-dev.install b/debian/iproute2-dev.install
new file mode 100644
index 0000000..00ba756
--- /dev/null
+++ b/debian/iproute2-dev.install
@@ -0,0 +1,3 @@
+include/libnetlink.h /usr/include
+include/utils.h /usr/include
+ip/ip_common.h /usr/include

Hello Evgenii Smirnov,

There used to be an iproute-dev package, which was removed by me.
There where no legitimate users, only abusers of this internal code
which is not a proper library to export as is for external consumption.
Also the internal libnetlink is as far as I know being phased out
even for internal iproute2 usage in favour of libmnl.
The existing users where ported over to libmnl where needed when
the iproute-dev package was removed.
I would suggest you base your own code around libmnl where possible
and if you're really modifying the iproute2 internals, then do that
by patching the iproute2 source (via debian/patches/) and rebuild
the package from source. If libnetlink is not yet fully phased out
in upstream iproute2 I'm convinced your help in porting it over to
libmnl is welcome as well! :)

I'm thus tagging this bug report as wontfix based on the historical
information and suggesting that it should be closed (but both of
these are really up to the new maintainers to decide on).

Regards,
Andreas Henriksson

Hi,

Personally I agree with your point of view - I wouldn't really be too
keen to maintain downstream some internal headers for public usage -
having to counter API breakages and so on.

If upstream committed to publish a public header, with all the
guarantees this would entail, that would change things - but I don't
see that happening.

If Alex also agrees then we'll close this.