Re: Patch: grep 2.5.1.ds2-6em2
On 7/23/07, Neil Williams <linux@codehelp.co.uk> wrote:
In the context of the whole package and in the
context of all packages that have been emdebianised so far, is it
*really* a "significant" amount of code being changed? I'm not sure that
"touching" so many packages with "Copyright Google" for such a small
amount of code (per package) is such a good idea.
Point taken. I agree that this is more about giving credit where &
when credit is due, and should not be about plastering copyright
statements unnecessarily.
Unless there is
an overriding reason, no Emdebian changes should use commands
from methods that are "foreign" to the Debian package and wherever
possible, Emdebian changes should use the highest level implementation
available so as to improve the chances of compatibility with future
releases.
Point taken. This should increase the fun factor somewhat :)
This is exactly the kind of work I have wanted to do recently but I've
been held up by bugs in the tools and infrastructure scripts. I would
love to know how the upgrades have gone - perhaps some stats on a
DebianWiki page or some indication of how many upgrades broke, how many
manual changes and fixes were needed etc.
I have selected 94 packages that I think a useful base system should
contain, and here is the breakdown:
44 are current against sid,
15 have newer versions in sid, but Emdebian patches (other than
against changelog) applies successfully,
22 have newer versions in sid, and some Emdebian patches fail to apply,
12 do not have Emdebian patches in svn,
1 is obsolete (linux-kernel-headers is replaced by linux-libc-dev).
Note that some false-positives in the "current" set. For example,
zlib1g counts as "current" only because all its svn Emdebian patches
are empty, and the built packages still contain man pages and
changelogs.
1. Updating emdebian packages against new Debian releases should be as
automatic as possible. Changes should be only required rarely. dpkg
filtering and other methods (like separate translation .deb files) will
assist in this area in the future, as will other changes within Debian
itself.
Are there any ongoing projects toward achieving this goal?
3. Previously, all such contributions have been handled by simply
allowing SVN commit access but the idea was to divide the current
access into SVN-only and Emdebian-developer access. Unfortunately, this
has not yet been implemented. Wookey (project lead) is currently on
vacation and he normally organises access to the Emdebian machines.
For the moment, I think me posting interdiffs here and you yelling at
me when I do things wrong seems to work for me, and the messages in
the list archives would serve as a guide for perspective developers.
4. I am currently trying to sort out powerpc toolchains and this
involves including .deb package files from a remote server into the
Emdebian toolchain repository and the same methods could be used to
update Emdebian packages from a location on one of your machines. In
effect, we could start the process of updating emdebian packages and
get some information on just how to run an autobuilder for cross-built
packages for Emdebian. The simplest way to do this is to make
the .changes files (with all listed files) available in a directory that
can be either rsync'd to or read directly from the Emdebian server.
(i.e. the same files that would need to exist to use dput, only in this
case it would be more like a dpull until access is sorted out.)
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.
6. Real data on how many emdebianised packages can actually be upgraded
automatically would be very useful.
See above in the post. Unless there are tools I am not aware of, the
Emdebian-patch-based approach requires human intervention when a new
Debian version changes one of debian/rules, debian/control, and
friends and makes a patch fail to apply.
--
Chuan-kai Lin
Reply to: