[arch-dev-public] Adding multi arch, pkgver and/or pkgrel support in repo scripts

[Pierre Schmitz]

On Thu, 3 Feb 2011 17:33:10 -0500, Eric Bélanger wrote:
> On Thu, Feb 3, 2011 at 6:23 AM, Pierre Schmitz <pierre at archlinux.de> wrote:
>> 2) check_splitpkgs: get correct arch for svnnames
>> Feel free to send me you ideas or some rough patches for a review.
> 
> I got rid of that function. It seemed to be used to make sure split
> packages all have the same pkgver and pkgrel which is not longer
> relevant. I suppose it could be readded later on with some of my
> changes in it.  So far, I'm trying to get the correct logic so there's
> some code duplication that might be moved to a function eventually.

This function should not be removed but improved; e.g. a check if
missing if a split package was removed and then automatically remove the
split package from the repo. This function ensures that the repo
contains the same as abs/svn.
 
>> But: I don't like supporting different pkgver or pkgrel for split
>> packages. Imho this is a feature of makepkg that has issues by design:
>> * Source packages with the same file name no longer point to the same
>> packages
> 
> I haven't thought about the sourceballs script yet but there might be
> a way to tell it to update the sourceballs.  Also, the reason we have
> these sourceballs is to comply with licenses. As long as the upstream
> sources are there, it shouldn't be a major problem if the PKGBUILD
> inside them is a little bit out-of-date.  So it shouldn't be a stopper
> IMO.
> 
>> * The repos subdir in svn (might) no longer contains the PKGBUILD that
>> a package was built with
> 
> I don't see why or how this would happen. The trunk gets copied to the
> repos subdir with archrelease.

We can no longer guarantee that a package in the repo was built with
the PKGBUILD in the svn/repos dir or abs. Or in short: you cannot use
abs to rebuild the repo.

>> * Same issue with ABS which is no longer in sync with the actual binary
>> packages
> 
> I believe that ABS use svn to gets its data. As I said above, it
> shouldn't be affected.

It sure is. What you propose is just being more relaxed on integrity
and literally decouple the binary repos from svn. This is not a minor
straight forward change and should be done right. In fact I already had
some ideas about this. I could send a more detailed mail if wanted. In
short it repos like this:
* Use svn just for trunk (or other branches) but no longer try to "tag"
what is actually in the repos. Means removing the repos subdir
completely.
* Instead switch to a pure package based approach. dbscripts will only
know about single packages. (would still need an integrity check to
search for removed split packages)
* Improve makepkg to create source packages with every build. Should be
like $pkgbase-$pkgver-$pkgrel-$arch.src.tar.xz
* Upload these source packages together with the binary packages and
store them in another repo
* If you need the pkgbuild of a package (e.g. for abs) just look for a
source package that corresponds to the scheme mentioned above
* Note that the db files is the only place where information are stored
in which repo a package exists.

> - i18n packages, I've seen it in (open) libreoffice and koffice.
> Sometime, they don't release new version of some of these i18n package
> (or release them later) but the old version is still usable.
> Currently, the package function of these languguage pack is commented
> out in the PKGBUILD but the package is kept in the repo. So we end up
> with a broken ABS and the integrity check complains. Support of multi
> pkgver/pkrel in split package would fix that.

These packages are a hack anyway. Upstream has different source
packages for every language. We collect them into one PKGBUILD and split
them again. There is no sane way to keep removed languages here. (and
also no need; if they were removed by upstream we should do the same.)

Summing up: We really should not try to support different versions of
split packages with our current svn repo setup. Instead we should
rethink the whole setup first as described above. Then we can easily
implement this in a clean way.

Greetings,

Pierre

-- 
Pierre Schmitz, https://users.archlinux.de/~pierre