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

Re: Patch: grep 2.5.1.ds2-6em2



On Tue, 24 Jul 2007 12:09:33 -0700
"Chuan-kai Lin" <cklin@google.com> wrote:

> Stale packages: adduser apt aptitude bzip2 cdebconf devmapper dhcp3
> dialog diffutils dpkg e2fsprogs file gcc-4.2 glibc gzip libselinux
> libsepol module-init-tools nano shadow tzdata wget

Updates to those are very welcome. A step towards a method to automate
updating these and other packages is even more welcome.

> Packages not emdebianized: console-tools cyrus-sasl2 db4.2 db4.3
> debconf debian-archive-keyring gdbm gnutls13 libcap libgcrypt11
> libgpg-error libice lzma newt opencdk8 openldap2 openssl slang slang2
> sysklogd ucf vim

debconf? You've got perl-base and perl to cross-compile? Are all those
built *with their dependencies* or just built as-is?

(Note: most Emdebian systems are not going to want perl at all and a
significant amount of effort is going to be needed to convert
postinst and other maintainer scripts from perl to dash - bash will
also disappear so no bashisms are allowed!) 

> > (I don't mean to yell). With lots of packages, using a branch in
> > Emdebian SVN is quite useful because it makes it easier for me to test
> > the revisions.
> 
> Hey, I was half joking.  No offense taken.  Are there existing branch
> naming conventions?

None - just put them under branches/ above the relevant trunk/. There
are multiple trunk/ levels within Emdebian SVN, typically package
specific patches exist in f/foo/trunk where f/foo also contains tags/
and branches/ so your changes are best in f/foo/branches/baz. You can
use numbers, names, anything you like.

> > Please let me know what changes are required in emdebian-tools to
> > achieve these native builds because it is something that Emdebian
> > would like to be able to do.
> 
> So far I have done well with simply replacing the dpkg-cross version
> of dpkg-buildpackage and dpkg-shlibdeps with the ones from dpkg-dev.

dpkg-cross should do that for you (as it does when I build an amd64
package for Debian on my amd64 box). Just specifying --arch amd64 on an
amd64 box will do that. Check the dpkg-cross perl code.

> I replaced dpkg-shlibdeps because the dpkg-cross version checks for
> cross-building libraries in $crosslib with "dpkg --search" which is
> hard to fool (even symlinks would not work).  I replaced
> dpkg-buildpackage because aptitude fails to build with the dpkg-cross
> version for some mysterious reason I have yet to uncover (pkg-config
> fails to find sigc++-2.0).

Those bugs need to be identified and fixed.

> Other than that, dh_make complains about missing or old cross
> toolchain, but it still seem to work (I have not looked at its output
> closely yet).

Interesting.
 
> > Some form of delta handling could be used for debian/control and
> > debian/rules too. This is completely untested but I think that because
> > we have the old Debian source backed up, we have the new Debian source
> > unpacked and we have the current Emdebian patches, we should be able to
> > calculate a patch that takes us from the old source through the new
> > source to the final Emdebian version. e.g. if the Build-Depends
> > line of foo_0-1 was changed in foo_0-1em1 and then foo_0-2 arrives with
> > other changes to Build-Depends, it should be possible to isolate the
> > changes from 0-1 to 0-2 (easy), diff against the changes for 0-1em1 and
> > come up with a patch that goes from 0-2 to 0-2em1 ?
> 
> I have seen lots of discussions on these topics among the CMS crowd
> (e.g., developers of subversion, mercurial, monotone, darcs, ...), and
> I think the general consensus is that what you proposed is possible
> only if the delta-merge program knows about the syntax and semantics
> of the changes between merged.  Line based diff and patch will not get
> us very far in this direction.

That is useful because, of course, emdebian-tools does know (or can be
shown) the context of the changes because we know all the formats that
we need to change: changelog, control, rules and .install files. All
have strict syntax and semantics. e.g. changes in debian/control should
be constrained to Build-Depends[-Indep]: (translation issues aside) so
if a package needs to migrate a Build-Depends: libfoo0 (>= 0.1.2) to
libfoo1 (>= 0.2.0) there are mechanisms available to emdebian-tools to
understand that this change should be present in the final merge unless
the emdebian package dropped that dependency entirely (e.g. because it
was used to generate documentation).

I've done quite a lot of work on merging data sets under strictly
controlled syntax and semantic control in C. QOF [0] can merge books
[1] of declared C objects without problems by looking up the syntactical
and semantic rules that must be followed by the data constrained within
instances of those objects. The code is part of gnucash and used by
other QOF-based packages in Debian. There is always some level of
user-intervention necessary but a rule-based merge of objects known to
follow a strict syntactical and semantic rule set can resolve most
conflicts that would cause a simple patch to fail. With the added rule
that Debian > Emdebian (i.e. changes to the Debian package metadata
always overlay changes to the Emdebian package metadata), you have a
situation that has all the hallmarks of a typical PDA synchronisation
routine (which I have also done upstream in C) and those can routinely
operate without user intervention by following those strict rules.

I'm not saying it can be done quickly, I'm just saying that it is
perfectly achievable.

[0] http://qof.sourceforge.net/
[1] http://code.neil.williamsleesmill.me.uk/merge.html

See also: http://linux.codehelp.co.uk/#qof

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Attachment: pgpsDiKYKVJTo.pgp
Description: PGP signature


Reply to: