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:
pgpGfk8OD6NfJ.pgp
Description: PGP signature