* Modestas Vainius <modes...@vainius.eu> [090804 11:37]:
> previous reprepro versions (3.5.2-6 in lenny for sure) used to allow to define
> and use Architecture: all in conf/distributions. Now I get this error in such
> a
> case:
>
> Error: Distribution abcdef contains an architecture called 'all'.
> There have been errors!
>
> You may wonder what I have been using it for so I will explain. It is common
> problem with Debian archive that once a new version of the source package that
> has both arch:all and arch:any binary packages is uploaded to the archive,
> arch:all packages are propagated to all architectures in the "Architecture"
> field. This effectively means that until a new version is built for other
> architectures, the package on them is very likely to be uninstallable to due
> newer arch:all packages in their Packages files. So here it is how I solved
> this
> problem (with lots of custom scripting):
>
> 1) Whenever including a .changes file (which has both arch:all and arch:$arch
> packages), -A $arch is used to prevent arch:all from being included into other
> arches.
Nice to see that feature used. I was almost considering allowing
different arch all packages would only cause problems and noone use it.
> 2) Those arch:all packages from .changes are included into Architecture: all
> section of the archive via dynamically generated pulls. Hence Architecture:
> all
> always has the newest arch:all packages.
I guess I should finally implement the planed -A arch1,arch2 which would
obsolete this step.
> 3) Whenever including binary-arch .changes of $arch, pull rules get generated
> dynamically to pull the requested version of the arch:all packages from
> "Architecture: all" section (remember, "Architecture:all" always has the
> latest
> arch: all packages) to our "Architecture: $arch" section.
>
> This way "Architecture: $arch" is never broken and "Architecture: all" is used
> as a staging area for arch:all packages. I have not tested yet if I could use
> "Architecture: dummy" rather than "Architecture: all" as such a staging area
> for arch:all packages, but I believe I can hence the bug is wishlist. However,
> it would be great if you could implement such inclusion behaviour in reprepro
> itself. Just let me know if you would like to see my scripts.
I've considered addings something like that (using the 'embargoalls'
Tracking mode), but that was more complicated than I thought.
(Especially as I mostly planed it for updates, so that architecture all
packages are embargoes until they can be used).
> Alternative solution (and probably easier overall) to the problem would be to
> keep old arch:all packages in the Packages file (and pool) until all
> arch:$arch
> (of the same version) for new arch:all packages are available.
It's sadly a deep assumption in reprepro's code and database layout,
that there is only one package of a given name in each
codename|architecture|component triplet. I hope to avoid that in the
next database redesign, but that will take a long time till there.
> This looks like the task of
> "Tracking", but it does not seem to affect Packages file processing (unless
> I'm
> missing something) even if debs themselves are kept around.
Indeed, tracking only can keep additional files in the pool, not
duplicate packages in the generated Packages files.
Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
