Re: cygport-0.9.3 in release-2

["Yaakov (Cygwin Ports)" <yselkowitz@users.sourceforge.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Charles Wilson wrote:
> Even the "rollup" patch?
> ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20060909-patch.sh.bz2

Yes.

> It only breaks the ABI (B?) if you do it the way you suggested:
> http://cygwin.com/ml/cygwin/2008-05/msg00038.html

Yes, the concept is the same:  ABI breakage affects previously-built
source packages but doesn't necessarily break API (IOW the .cygport
wouldn't need to be changed, but you'd need to fetch() from scratch).
API breakage affects the programmer, i.e. the .cygport itself would
require a change.

> There's really no "rule" like '-d ${CVS_MODULE##*/}' that is universally
> applicable: the module name and the -d option (if present) are
> orthogonal controls. You don't want to tie them together.
> 
> The way my patch does it, there is no API breakage -- but you have a new
> API entry point [the new CVS_DIR variable].  The price of API
> preservation is a proliferation of new ones; just ask Bill Gates.

I should learn about API preservation from Micro$oft?!?  Are you joking?
 http://en.wikipedia.org/wiki/Criticism_of_Windows_Vista#Software_compatibility

OTOH one can definitely learn from GNOME, whose developer platform has
maintained API compatiblity for 6 years while steadily adding new
features every six months.

I have been trying to maintain ABI/API stability, although I wouldn't be
surprised if I broke something along the way.

> The benefit of allowing some mechanism to pass a -d option to the cvs
> checkout is that I can ensure that my cvs.cygclass-generated origsrc
> tarball has the same directory layout as a make-dist-generated one.
> 
> But whatever. I'll live with it. Worst case, I'll manually repack the
> tarball and comment-out the inherit cvs.cygclass. Besides, the only
> package I know of that has this issue is libgeotiff -- which moved to
> subversion a few months ago, anyway.

Out of 2018 packages in Ports SVN, a quick grep showed that 13 currently
inherit cvs.cygclass (vs. 32 using SVN), and out of those, only one
(ocaml-xml-light) has a deep CVS_MODULE.  The fact that the sources are
deeper than they need be is IMO not an issue because it is handled by
cvs.cygclass without intervention.

> So, it's probably moot for all current packages.

Agreed.

> It is sufficient to override the default behavior of the post-install
> phase with respect to documentation; that's what the urxvt packages care
> about. But other packages (unknown at this time, but I'm not possessed
> of sufficient hubris to rule them out) might need to override/customize
> some other phase:

IOW it's purely hypothetical.  I haven't found a case where this would
be necessary either.  If you do find something, I'll be happy to look at
it, but cygport development has always been driven by practical usage.


Yaakov

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkkXtmQACgkQpiWmPGlmQSND/QCg2ZEvZZiR8mRJ5deX+o8QqBhi
M5AAniHfGhbNbtPK9QRmbbAXOR8dj8Lr
=Xat9
-----END PGP SIGNATURE-----