Hi, On Tue, Dec 13, 2005 at 21:57:22 -0600, Jonathan Asghar wrote:

Hey guys...

...

giulivo someone can help me to understand the new ports organization and how to synch with it in the best way using cruxppc? It's mainly to interface with the new trac web page and svn repo that was put in place. I bet there is away to make make another trunk so we could have specific ppc Pkgfiles, but we need to make some movement first. I think it's important to note that subversion nor any other VCS I know is powerful enough for the sync use cases I know (which is x86 <-> sparc <-> x86_64).

When considering the multi-arch question, I'd like the following requirements to be met: 1. No single master tree (i.e. not all master ports in x86); this is a real probem already now, as some maintainers are moving from x86 to x86_64 2. No untested ports distributed to users 3. Reduce the work load for maintainers on new architectures, and for updates of synced packages 4. No special cases: CRUX' ports should be the same, independent of the architecture In order to have a successful discussion, I think we should first make sure that we define similar requirement everyone can live with, before plunging into details. However, to give those new to the subject some background, here's a list of approaches previously discussed und formerly used in some ports (PPC, uCRUX, x86_64, SPARC): ---------------------- 1) All in one Pkgfile (the gentoo approach) Here, a Pkgfile would contain things like if [ "$arch" = "sparc64" ]; then elif [ "$arch" = "ppc" ]; then elif [ "$arch" = "ppc" ]; then ... fi Pros: - generic changes are available on every platform easily Cons: - ugly Pkgfiles - in order to allow different platforms to have different versions, the Pkgfiles' names must include a version, and the Pkgfile must include a field which says "known to work on platform X"; this again makes the package management tools more complex Conclusion: There's a certain consens that this is not a CRUX-like solution ---------------------- 2.1) The file override approach With a a magic Pkgfile name (Pkgfile.$arch overrides Pkgfile), provide a way to override Pkgfiles Pros: - no work required if a Pkgfile works on the target platform Cons: - It introduces special cases, making the package management more complex (think: "if there's a Pkgfile.$arch, use that one") - The special cases make it also harder for users to understand the system - If there are both Pkgfile and Pkgfile.$arch, and the Pkgfile is updated, chances are the $arch maintainer has to merge the changes manually - It invites to do ugly tricks (like sourcing the Pkgfile, and only changing vars) - requires one master architecture - Main disadvantage: It invites to provide untested ports from other architectures, and only fixing them (by providing a Pkgfile.$arch) if there's a problem 2.2) The repo override approach Very similar to the above, however using separate collections to override "broken" ports. That's what both the ppc and x86_64 ports did in the past (not sure if that's still the case). Pros: - no work required if a Pkgfile works on the target platform Cons: - The special cases make it also harder for users to understand the system - If there are both Pkgfile and Pkgfile.$arch, and the Pkgfile is updated, chances are the $arch maintainer has to merge the changes manually - requires one master architecture - Main disadvantage: It invites to provide untested ports from other architectures, and only fixing them (by providing it in the override repo) if there's a problem Conclusion: The fact that a port shows up in $ARCH because it's in $OTHERARCH seems wrong to me; it should be there because there's someone looking after it. Also, this approach requires one master architecture, which seems to become a problem as former CLC/x86 people are now working only on x86_64 (yes I mean you, Daniel! ;-)). ---------------------- 3) The branches/pure VCS approach Back in the days when we last time discussed this, several from us (me included) considered this a viable solution: basically we'd just use different branches in a VCS to keep track of changes. We've tried it for CRUX/Sparc. Pro: - Automated merging possible - Independent ports versions easily possible - Only tested ports/updates get to the branch Cons: - requires one master architecture - the common commands often aren't helpful for maintainers: you don't actually care about all diffs to a parent tree, just the ones you maintain. - usually doesn't store the url of the master repo, i.e. in svn you have to run 'svn diff <url>' to diff from arch X to Y. Conclusion: It seemed like a good idea, but in real life, it didn't work out that well, and wasn't practical. The fact that it requires one master architecture is another major problem. ---------------------- 4) the "smart merge tool" & one master port approach Finally, this is the method I consider best. It's based on the mppm tool which is/was used for uCRUX, and was suggested to the PPC team when we discussed it. Not sure if they tried it. The basic idea is that for every port in the CRUX universe (consisting of many architectures), there's just one maintainer (aka primary maintainer). On the other architectures, a arch maintainer just makes sure a port works on this architecture. This has a couple of interesting properties: - the ports tree is quite unified. CRUX feels the very same on every architecture - the primary maintainers can work on their favorite architecture (i.e. no master architecture needed) - being an arch maintainer does't require as much work as being a primary maintainer (given that the primary maintainer does most of the port specific work, like following the development), which _should_ allow even small groups of people to maintain an arch port while still only providing tested ports On the technical side, I proposed to have a smart tool which can do automated (three way) merging and track just your ports. That means the arch maintainer would run $ stm sync $ stm diff And see only the ports he/she maintains which were changed. However, this smart tool requires the ports to be on your Pro: - only tested ports are distributed - automated merging possible - arch maintainer job causes not too much work - clear responsibilities between maintainers - unified ports tree - copes will with primary maintainers on different architectures - starting a new arch port doesn't need write access to existing repositories - VCS-agnostic: arch X can use CVS, while arch Y uses Subversion. Cons: - requires to have the master ports locally, which right now would mean that a maintainer on PPC would need both x86 and x86_64 trees - requires us to write this smart tool :-) Obviously, the only solution which meets my initial requirements is the last one which isn't surprising since the requirements were there before, and #4 was my take to meet them. However, as mentioned previously, I'd suggest we try to find a common goals first, before going into the discussion of how to realize it. Best regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net