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

[Michał Masłowski]

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20120127/cec54773/attachment.sig>