[Dev] [issue370] [mips64el] don't have unnecessary repos in abslibre-pre-mips64el and abslibre-mips64el

[Nicolás Reynolds]

On Fri, 27 Jan 2012 18:48:53 +0100, mtjm at mtjm.eu (=?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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20120129/cdbaa122/attachment.sig>