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

how to implement vendor support



Taking a look at avahi in particular and the current Wiki page:

http://wiki.debian.org/EmdebianAuditDetail#Vendor

It becomes fairly obvious that specifying each vendor in the
debian/rules file of each package is not going to be as flexible as
dpkg-vendor support could actually afford to implement.

As such, we need a way for debian/rules to call in a string for a
particular package that fits into the rules for that package *and*
conforms to the requirements of the vendor.

e.g. avahi debian/rules patch:

DEB_VENDOR=$(shell dpkg-vendor --query vendor)
ifeq (,$(findstring emdebian-crush,$(DEB_VENDOR)))
  # Debian build
  EXCONFARGS=--disable-mono --disable-monodoc
else
  # emdebian build (crush)
  EXCONFARGS=--disable-mono --disable-monodoc --disable-python \
 --disable-doxygen-doc --disable-pygtk --disable-python-dbus
--disable-core-docs \
 --disable-qt3 --disable-qt4 --disable-gobject --with-distro=debian 
endif

So, that could become:

DEB_VENDOR=$(shell dpkg-vendor --query vendor)
ifeq (Debian,$(DEB_VENDOR))
  # Debian build
  EXCONFARGS=--disable-mono --disable-monodoc
else
  # any-vendor build
  EXCONFARGS=$(shell foo-bar --vendor $(DEB_VENDOR) --package avahi --key EXCONFARGS)
endif

or use the short options:
  EXCONFARGS=$(shell foo-bar -V $(DEB_VENDOR) -p avahi -k EXCONFARGS)

Then, we might have a file in /etc/ and a script that reads the values.

The files themselves would be in /etc/foo-bar.d/ on a per vendor basis,
each file being a control file format listing the strings.

$ cat /etc/foo-bar.d/emdebian-crush
[avahi]
EXCONFARGS=--disable-mono --disable-monodoc --disable-python
--disable-doxygen-doc --disable-pygtk --disable-python-dbus
--disable-core-docs --disable-qt3 --disable-qt4 --disable-gobject
--with-distro debian 

[busybox]
foo=


(Note that the value has to be all on one line which is a little
awkward - also note that values would not be able to include the equals
sign which could be more of an issue.)

Packages that need two strings could do so - the key string is entirely
arbitrary as long as it fits in the style of a typical ini file.
Therefore, the key can be matched to the needs of the relevant package.

The pseudo-perl script to do this is simple:

#!/usr/bin/perl

use Config::Auto;

$cfile = "test.conf";
my $sandbox = Config::Auto::parse("$cfile", format => "ini");

use Data::Dumper;
print Dumper ($sandbox->{'avahi'}->{'EXCONFARGS'});

(The manpage content is double the size of the script!)

So, I think we will have 'emvendor' in emdebian-buildsupport.

Files would go into:
/etc/emvendor.d/

emdebian-buildsupport would provide /etc/emvendor.d/emdebian-crush with
all the content for all packages that need such details.

The call would be:
  EXCONFARGS=$(shell emvendor -V $(DEB_VENDOR) -p avahi -k EXCONFARGS)

It's probably an option that could go into dpkg-dev at some point.

This support will need to get into the relevant Debian packages via
bug reports and patches.

The remaining problem is what to do with commands in maintainer scripts
where the *command* is supported by busybox but the specific *option*
is not. (like grep -x)

Thoughts? 

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/

Attachment: pgpYn_lcZ2pCg.pgp
Description: PGP signature


Reply to: