On Fri, 27 Jan 2012 18:48:53 +0100, [email protected] (=?utf-8?Q?Micha=C5=82_Mas=C5=82owski?=) wrote: > > For PKGBUILDS which need more changes it may be good to have a different > > file named PKGBUILD.mips64el (or .$arch) and instead of a different repo > > for testing a testing folder or a testing-PKGBUILD. > > PKGBUILDs aren't the only files in the pkgbase folder, so separate > folders would be needed. However, it would reintroduce the problem of > having to merge changes for mips64el or for our other arches. > > Why not have branches, like arch-extra, arch-testing, parabola-extra, > parabola-testing, with no architecture-specific things? > > I think it would more easily support merges between testing and > non-testing repos. > > > Thats for maintaining abs. We could use traditional abs to build using > > libretools unchanged. > > Building often needs changing the PKGBUILDs, I wouldn't try using > another abs for building to upload a package (I use an abs tree only for > unpacking sources of possibly non-FSDG packages). > > >> - boring and bug-prone merge is needed for an update from > >> abslibre-pre-mips64el > > > > In most cases this would be an automatic cherry pick and when more > > changes are needed it would be a manual process. > > I've noticed several times patches/PKGBUILD-lines "disappearing" from > gcc or glibc, this would be a good change (I don't want to change the > gcc PKGBUILD unless necessary). > > >> - abslibre's changes aren't properly versioned in abslibre-mips64el, just > >> saved > >> daily without original commits > > > > I try to use librecommit which makes that, our automatic script could > > commit using librecommit too thus making easy this versioning. > > This will be solved by having a single repo for package used on all > arches. The automatic script would need to make commits using mostly > original metadata, this would be more complex than using a single repo. > > >> - changing libre packages for use on other arches needs a separate repo, > >> not > >> used for mips64el building > > > > This I don't get it > > I use my YeeLoong sometimes when fixing non-mips64el-specific bugs, > e.g. packaging epdfview-libre, updating texlive-bin-libre or fixing > texlive-core-libre to not conflict with texlive-langextra. I don't use > abslibre-mips64el for such changes, since it would make merging changes > to build on other arches more complex. > > >> - we need to merge mips64el-specific changes in our repos like libre, while > >> there is no need for that > > > > This wouldn't be needed either in the system I propose because mips64el > > specific changes would be in a different file. > > The problem is merging changes from the different, non-mips64el, file to > the mips64el one, my description of the problem was wrong. I believe > such merges are harder than ignoring mips64el-specific lines in the > single file for all arches by other Parabola packagers, like they > already do with i686-specific or x86_64-specific changes (since most > packagers use only i686 or only x86_64). > > >> - we sometimes fix non-mips64el-specific problems in libre which are later > >> needed on x86_64 > > > > Again this would be solved. > > Solved by not having a mips64el-specific file or branch.
while i agree that the current workflow is extremely opaque, complex and boring, i don't see the need to re-engineer abs to accomplish it... to avoid more breakage we should follow upstream since most of the changes come from there. arch's svntogit is converting the svn structure $pkgbase/$repo.$arch/ to git branches packages/$pkgbase or community/$pkgbase so contributors only checkout the packages they need. the problem i see with this is that automatic scripts should constantly shift branches to get different packages? the opaqueness is my fault. i hacked the updating script directly on the server but haven't pushed it to dbscripts.git or any other code repo. i plan to move it to dbscripts this week.
pgp0SvSZ0NDUp.pgp
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] http://lists.parabolagnulinux.org/mailman/listinfo/dev
