On Mon, 2004-12-20 at 14:52 -0500, Dimitrie O. Paun wrote: > On Mon, Dec 20, 2004 at 11:15:36AM -0500, Colin Walters wrote: > > On Sun, 2004-12-19 at 23:49 -0500, Dimitrie O. Paun wrote: > > > > > That's an idea that I've been playing with myself. > > > > You also have a build system? > > Nothing that works, no. But I'm planning on setting one up, based > on arch. Thinking about it, I've reached the same conclusions you > had, which is what got me into this thread in the first place :) Cool. It definitely seems to me there's a lot of interest in a new build system; there's mach, beehive, rookery, the fedora.us one, and probably tons of others. Maybe we should make a new list for this; or maybe use the RPM list? > Goes without saying. But before we can write one, I have to have at > least a clue how it's going to work out. Right; well I think in this case both would generally work. In your scenario, the other branches essentially just become an implementation detail of the first branch. > But speaking of the branches, this is what will make or break such system. > Explicitly defining them in the .spec file is one way. More work, but: > 1. you get more control > 2. it's easy to add/delete/reorder things. Well you need to define them somehow. My idea was that the build system would automatically do a 3-way merge *at build time*, based on the Branch: headers. If that failed, it failed the build and kicked it back to you, just like it does now for applying a patch. > However, it's still not clear how it's going to work. Without merging > patches, how do you know they don't conflict? You'd just build on your local machine for testing, or use a 'scratch' area in the build system. > Even if they don't, they > may introduce fuzz for the others. I think you'd want an option to disable fuzzy patch application for whatever RCS is in use; or maybe you get a build warning if there's a too-fuzzy patch; e.g. over 5 lines displacement? This is just detail though. > It seems to me the only way you are guranteed things will work is only > if you have the RCS system handle the order in which you do the patches > as well. It's not clear to me that ordering is really all that useful if we make it easy to create new branches that merge from two conflicting branches. When would you want to reorder patches other than to work around conflicts?
