Re: Patch: grep 2.5.1.ds2-6em2
On 7/24/07, Neil Williams <linux@codehelp.co.uk> wrote:
"Chuan-kai Lin" <cklin@google.com> wrote:
I am unsure whether
emdebian-changelog.patch would actually contain enough useful data to
make it worth inserting old entries - we have SVN to record the
history of the patch file itself.
I agree that keeping old entries is not all that important. I think
of Emdebian not as maintaining our own line of package development and
maintenance, but as constantly producing embedded-variants of Debian
packages. With this perspective 1.2-1em1 (for example) does not
really grow out of 1.1-3em1, and having the 1.1-3em1 entry in the
1.2-1em1 changelog provides little useful information.
What we do need is to tell 1.2-1em1 from 1.2-1em2... but without a new
Debian version, emdebian-changelog.patch should apply cleanly.
> 22 have newer versions in sid, and some Emdebian patches fail to apply,
> 12 do not have Emdebian patches in svn,
OK, can you give package names for those 34 please?
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
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
I miscounted yesterday -- there are 22 packages without Emdebian
patches in svn, and only 34 packages (instead of 44) are current
against sid.
If you get them to build, patches would be appreciated or if you can
send your SSH key and preferred username to Wookey before he leaves,
you could commit the revised patches yourself, as a branch.
I have sent an access request to Wookey, and I am planning to work
through these packages in the coming weeks.
(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?
> I am not planning to make any built packages public because I am not
> building them through the standard procedure. I build Emdebian
> packages natively, and I currently find it more convenient to hack
> Emdebian tools to use the native toolchain instead of building and
> installing an i386 -> i386 cross toolchain.
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.
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).
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).
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.
--
Chuan-kai Lin
Reply to: