> 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.
pgpN4RBVvkC5h.pgp
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] http://lists.parabolagnulinux.org/mailman/listinfo/dev
