On Wed, Nov 09, 2005 at 11:07:24AM +0900, Horms wrote: > On Tue, Nov 08, 2005 at 04:48:04PM +0100, Sven Luther wrote: > > Hi all, > > > > As you may have noticed, i did some tests to illustrate my proposal to split > > the infrastructure out of the real packaging, which you can find at : > > > > svn://svn.debian.org/svn/kernel/dists/test > > > > The layout is as follows : > > > > linux/infrastructure/debian <- contains the common stuff. > > linux/versions/<version>/debian <- contains : arch, patches-debian, > > patches-arch > > > > I have added symlinks from each version to the infrastructure stuff, but > > ideally we would have a way to handle this better. I am thinking of an > > export > > debian/control rules, which would do the right thing and prepare an > > uploadable > > directory, doing svn export, unpacking the upstream tarball and pruning it > > or > > using the debian dir and so on. > > > > The one problem which needs a bit more though would be the changelog field, > > which i didn't know where to put, as there are the per-version changes and > > the > > infrastructure changes, maybe we need a Changelog.infrastructure or > > something > > like this, and that we should also pull in the k-p changelog at built time. > > > > Comments on this are welcome. > > > > Another idea would be to have the following layout : > > > > linux/debian <- all the common stuff. > > linux/debian/2.6.12 <- the 2.6.12 stuff. > > linux/debian/2.6.14 <- the 2.6.14 stuff. > > > > All in a single place, and we can just exclude the not-needed directories > > from > > being included in the debian/rules export target. > > Hi Sven, > > While I think keeping common code common is important, > isn't this something our version control system should > be doing for us with branches and merges? I'm concerned > that your approach adds extra complexity to achive > much the same goal.
Yes and no. The problem is that basically we have two different things, the first one is the build infrastructure, which should really not be all that different for each version, and which there is really no need to have a branch per version from. On the other hand, the per version configs and patches cannot be done without, and thus should be hold in a different branch each. This indeed adds some complexity (rather minimal though if done right), but on the other hand it will keep the branching to the absolute minimum, and weren't you the one complaining about too many branches ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
