Thu Aug 14 20:47:00 GMT 2014
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
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf rackAttack V1.04R1:
More information about the Cygwin-apps