0

Which is the purpose of the binary-all architecture folder on debian repositories?

1 Answer 1

1

From the Debian Policy Manual:

Depending on context and the control file used, the Architecture field can include the following sets of values:

And from the Packaging Best Practices:

6.7.5. Architecture-independent data

It is not uncommon to have a large amount of architecture-independent data packaged with a program. For example, audio files, a collection of icons, wallpaper patterns, or other graphic files. If the size of this data is negligible compared to the size of the rest of the package, it's probably best to keep it all in a single package.

However, if the size of the data is considerable, consider splitting it out into a separate, architecture-independent package (_all.deb). By doing this, you avoid needless duplication of the same data into eleven or more .debs, one per each architecture. While this adds some extra overhead into the Packages files, it saves a lot of disk space on Debian mirrors. Separating out architecture-independent data also reduces processing time of lintian (see Section A.2, “Package lint tools”) when run over the entire Debian archive.

So, typically the binary-all packages are data files, or executables which are architecture independent (like scripts). By keeping these separate, the load on the repositories is reduced.

2
  • But the binary-all folder only contains the Packages files and no packages. That Packages files aren't read by amd64. The binary-amd64/Packagesfiles include all binary-all packages repeated. So I suppose, that since the existence of debian/pool folder, the binary-all folder is useless. Commented Jan 31, 2016 at 2:36
  • 1
    @ncomputers.org it looks like you're right: it might be a mistake to have binary-all. Commented Jan 31, 2016 at 2:47

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.