Package: reprepro Version: 3.11.1-1 Severity: wishlist Hello,
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. 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. 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. 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. I believe APT can cope with such Packages files properly. 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. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-rc4-amd64 (SMP w/1 CPU core) Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages reprepro depends on: ii libarchive1 2.6.2-1 Single library to read/write tar, ii libbz2-1.0 1.0.5-3 high-quality block-sorting file co ii libc6 2.9-23 GNU C Library: Shared libraries ii libdb4.6 4.6.21-14 Berkeley v4.6 Database Libraries [ ii libgpg-error0 1.6-1 library for common error values an ii libgpgme11 1.1.8-2 GPGME - GnuPG Made Easy ii zlib1g 1:1.2.3.3.dfsg-14 compression library - runtime Versions of packages reprepro recommends: ii apt 0.7.22~mdx2 Advanced front-end for dpkg Versions of packages reprepro suggests: ii gnupg-agent 2.0.11-1 GNU privacy guard - password agent pn inoticoming <none> (no description available) ii lzma 4.43-14 Compression method of 7z format in -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
