Helmut Grohne wrote: > You point out a limitation that I'd consider to be a feature. My > proposal requires that every package has a single set of running > architectures that has to apply to all code contained.
Should that "set of running architectures" be just "architecture"? I think that after adding such splitting of packages the system could represent the required constraints, but I'm not sure if such splitting is a practical way. > Having to split a small number of packages to achieve true multiarch > seems like a good trade off to complicating the dependency syntax to me. Have you tried to somehow count the affected packages? Where did you get the "small number" from? There are over 2500 packages with a dependency relationship on "python" alone that are not named "python-*" (to exclude python module packages). Is the proportion of those with Python scripts in addition to other code really that low? Would something like apt-file be split into 3 - apt-file, apt-file-perl-scripts, apt-file-python-scripts? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1366501352.1964.55.camel@glyph.nonexistent.invalid
