Marco Atzeri writes: >> Whether the package is available for both architectures > > Wrong expectation.
So what? I get how things are right now, that doesn't mean it has to stay forever that way. > It is in both architectures if it appears in both setup.ini; > any other solution will create duplicated information that finally > need alignment and it is error prone. Ultimately the need for this file sholud go away except for bootstrapping a new maintainer. > I plan to produce a list of sources by arch as by product of > the current analysis. > > Please note that the two trees are not exactly equal so there are > packages available only in 64 and not in 32bit > (biber is the first in alphabetical order) I know, I've done similar analysis before (in Perl, if that matters). > The build methods is maintainer choice. > I use cygport but I don't see a reason to mandate it. Corinna has already motioned in that direction and I'd say it makes good sense to converge onto a single package building method. That's the only way to ever get an automatic build off the ground. If and when that happens the only thing a maintainer has to do is upload a new cygport file and check the build logs before release. > I do not follow the rest of your statement, > could you clarify the expected outcome ? Long term: You enter a new maintainer manually and when the package is finally uploaded an extended setup.hint provides all the information that goes into the package database to fill the temporary blanks. And with a little bit of extra effort each package could eben be checked for (formal) correctness. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
