cygwin-pkg-maint maintance

[Achim Gratz]

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