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

Re: Bits from the dpkg project: 1.17.x series, general news



Hi!

On Mon, 2015-04-20 at 15:01:48 +0200, Thibaut Paumard wrote:
> Le 18/04/2015 21:27, Guillem Jover a écrit :
> >   Portability in dpkg is very important, to be able to support downstreams
> >   and people who use it on other systems, or even package it in other
> >   (non-GNU/Linux) distributions. But for many such systems I'm currently
> >   porting purely through documentation. And as such, subsequent build and
> >   run-time issues are clearly reactive, but I'd like to switch to a more
> >   proactive model. So I'd very much appreciate if either interested
> >   parties could provide access to such systems, or setup some kind of
> >   continuous integration system from git. I'm thinking specifically of
> >   systems such as non-glibc based Linux, FreeBSD, NetBSD, OpenBSD, Minix,
> >   Solaris, Mac OS X, HP-UX and AIX.

> Possibly stating the obvious, but a you aware that fink (a package
> management system for Mac OS X/Darwin) is based on a dpkg fork? Have you
> been in touch with them?

Yeah, I'm aware (<https://wiki.debian.org/Teams/Dpkg/Downstream>). I
try to keep track of the delta in all downstreams I know of, and try
to fix stuff on my own or merge what looks good. In the case of the fink
project, I've been in contact with them on and off and merged patches
from them and tracked down issues or got patches tested with their help.
But given that they are stuck with dpkg 1.10.x switching to the latest
branch has been a slow moving target for them. Also there's still at
least an unresolved reported test suite failure for dpkg-divert.

> The MacPorts projects also packaged dpkg (1.14.29).

Getting this to 1.17.x would be great.

> I can presumably update, build and test the macports package
> occasionally (it doesn't have an individual maintainer atm), but I
> cannot set up an automated framework (although MacPorts does have
> autobuilders).

Barring anything better, testing git master (or a released tarball if
that's easier) from time to time and reporting build or test suite
failures would already be great!

Thanks,
Guillem


Reply to: