From: [email protected]

This is a multi-part MIME message sent by reportbug.

Package: apt-utils
Version: 0.5.27
Severity: wishlist
File: /usr/bin/apt-ftparchive
Tags: patch

Unless I'm missing something in the documentation, currently apt-ftparchive doesn't support adding all of the packages in binary-all to the individual package files for each architecture. Looking at the Debian archive, this
is the expected behavior, and apt-get doesn't download the binary-all
Package file and therefore will miss any architecture-independent packages
in an archive indexed by apt-ftparchive.

Currently, other tools have to work around this by including all as an architecture and then merging Package files together, but that doesn't
address the Contents-* files, which have a similar problem.

The attached patch fixes this. It adds an IncludeAll boolean configuration option, defaulting to false, that if set to true will include the binary-all packages in every binary-$(ARCH)/Packages file (and from there, Contents
picks them up).

Please let me know if there are any problems; I'm happy to redo the patch
if needed.

-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.26
Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to C)

Versions of packages apt-utils depends on:
ii apt [libapt-pkg-libc6.3-5-3 0.5.26 Advanced front-end for dpkg
ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an ii libdb4.2 4.2.52-16 Berkeley v4.2 Database Libraries [ ii libgcc1 1:3.4.1-5 GCC support library
ii libstdc++5 1:3.3.4-3 The GNU Standard C++ Library v3

-- no debconf information

--- apt-0.5.27/ftparchive/apt-ftparchive.cc.orig 2004-01-02 13:48:13.000000000 -0800
+++ apt-0.5.27/ftparchive/apt-ftparchive.cc 2004-08-10 19:36:03.000000000 -0700
@@ -46,6 +46,7 @@
{
// General Stuff
string BaseDir;
+ string AllDir;
string InternalPrefix;
string FLFile;
string PkgExt;
@@ -185,6 +186,9 @@
{
if (Packages.RecursiveScan(flCombine(ArchiveDir,BaseDir)) == false)
return false;
+ if (AllDir != "")
+ if (Packages.RecursiveScan(flCombine(ArchiveDir,AllDir)) == false)
+ return false;
}
else
{
@@ -433,6 +437,8 @@
"$(DIST)/$(SECTION)/binary-$(ARCH)/");
string DSDir = Setup.Find("TreeDefault::SrcDirectory",
"$(DIST)/$(SECTION)/source/");
+ string DADir = Setup.Find("TreeDefault::AllDirectory",
+ "$(DIST)/$(SECTION)/binary-all/");
string DPkg = Setup.Find("TreeDefault::Packages",
"$(DIST)/$(SECTION)/binary-$(ARCH)/Packages");
string DIPrf

From: [email protected]

On Tue, 10 Aug 2004, Russ Allbery wrote:

Unless I'm missing something in the documentation, currently apt-ftparchive doesn't support adding all of the packages in binary-all to the individual package files for each architecture. Looking at the Debian archive, this
is the expected behavior, and apt-get doesn't download the binary-all
Package file and therefore will miss any architecture-independent packages
in an archive indexed by apt-ftparchive.

The expected operation is that whatever is invoking apt-ftparchive
arranges for things to be structured so that it sees binary-all files
while running. This is done in one of two ways:

1) New style pools way - the script that extracts the files lists unions
all and each arch together and produces a file list file compatible
with the FileList argument
2) Old style debian way - Even though there was a binary-all directory
the archive scripts were expected to maintain symlinks from binary-*
to binary-all.

Both allow apt-ftparchive to see the all files when processing a per-arch package file and it will produce the expected output.

If you really want to maintain an old-style archive without the symlinks
then I suggest you invoke apt-ftparchive using the FileList mechanism and
have an external script produce a unioned file listing (ie find
binary-all -type f && find binary-i386 -type f > flist.i386).

The flist mechanism is how apt-ftparchive supports all configurations
besides the old style debian archive with symlinks.

What are you trying to do anyhow? I can't think of any good reason to
split things up by binary-* unless you are maintaining a really big
archive.. For smaller archives it is OK to produce a mixed architecture
package file, apt/etc handle it just fine.

Jason



--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

Jason Gunthorpe <[email protected]> writes:

The expected operation is that whatever is invoking apt-ftparchive
arranges for things to be structured so that it sees binary-all files
while running. This is done in one of two ways:

1) New style pools way - the script that extracts the files lists unions
all and each arch together and produces a file list file compatible
with the FileList argument
2) Old style debian way - Even though there was a binary-all directory
the archive scripts were expected to maintain symlinks from binary-*
to binary-all.

Both allow apt-ftparchive to see the all files when processing a
per-arch package file and it will produce the expected output.

Ah! Okay.

What are you trying to do anyhow? I can't think of any good reason to
split things up by binary-* unless you are maintaining a really big
archive.. For smaller archives it is OK to produce a mixed architecture package file, apt/etc handle it just fine.

I'm trying to bring debarchiver's indexing up to snuff. I've been
submitting a flurry of patches to it -- it was originally using dpkg-scanpackages and dpkg-scansources, and now it can use apt-ftparchive
and can generate the per-arch Release files. But I was trying to solve problems I encountered in the right place, and from what documentation I
had, this seemed to be more of an apt-ftparchive thing.

With this additional information, I now know that debarchiver should be creating symlinks when it installs "all" arch debs, and I'll go back and
see about getting that change into debarchiver. (debarchiver doesn't
support package pools.) I'm using debarchiver because, of the available
apt archive maintenance utilities in Debian, it seemed to be the closest
to what I needed.

Thanks for your help!

For my future reference, is there any documentation I should have turned
to that would have explained this sort of issue? I'm coming into this a
bit blind, not having had long experience with Debian's archive format, so
I'm trying to puzzle things out from what I've happened to stumble across.

--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

On Thu, 12 Aug 2004, Russ Allbery wrote:

What are you trying to do anyhow? I can't think of any good reason to
split things up by binary-* unless you are maintaining a really big archive.. For smaller archives it is OK to produce a mixed architecture package file, apt/etc handle it just fine.

I'm trying to bring debarchiver's indexing up to snuff. I've been
submitting a flurry of patches to it -- it was originally using dpkg-scanpackages and dpkg-scansources, and now it can use apt-ftparchive
and can generate the per-arch Release files. But I was trying to solve problems I encountered in the right place, and from what documentation I
had, this seemed to be more of an apt-ftparchive thing.

Ah..

With this additional information, I now know that debarchiver should be creating symlinks when it installs "all" arch debs, and I'll go back and

Well, I frankly consider the symlinks to have been a bad idea. I think
you'd be better off with using file listings as I described for any new implementation. It is annoying to maintain the symlinks and there is
really no need.

For my future reference, is there any documentation I should have turned
to that would have explained this sort of issue? I'm coming into this a
bit blind, not having had long experience with Debian's archive format, so I'm trying to puzzle things out from what I've happened to stumble across.

Hmm, I'm not aware of any.

JAson



--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)