Re: cygport missing features after 0.3.9

["Yaakov (Cygwin Ports)" <yselkowitz at users dot sourceforge dot net>]

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

Charles Wilson wrote:
|  (a) my "orig" src tarball, if generated via cygport * get, has an extra
| directory level in it, that src tarballs created via 'make dist' do not
| have.

I suppose a cleaner solution would have been to add a '-d
${CVS_MODULE##*/}' to the checkout command, but doing that now would
break existing -src packages.

|  (b) I have to override all src_*() methods to add an extra 'cd
| MyPackage', because there is no Makefile or configure script in
| ${S}="..../StupidModuleNameThatHasNothingToDoWithMyPackage".
|  (c) Sure, to avoid (b) I could set
| SRC_DIR=StupidModuleNameThatHasNothingToDoWithMyPackage/MyPackage but I
| don't want to do that, especially because of (a).

cvs.cygclass sets SRC_DIR automatically, including in this case, so this
shouldn't be necessary.

| I want
| foo-1.2.3-1/src/MyPackage/*
| and an "orig" tarball that looks like
| MyPackage/*
| So I can treat it like a normal package. I can't do that without -d.

True.  But there are other packages where the toplevel is not SRC_DIR.

| You favor the cars-on-streets model: stay on the pavement, between the
| white lines, and everything will be fine. Cygwin
| package-building-on-rails is streamlined, easy, and usually works great
| even for newbies.  Except when it doesn't, and there isn't enough
| flexibility to go somewhere offroad.

Fair enough, but I think that I have the experience to say that cygport
*CAN* go just about anywhere nowadays, even on its "rails".  Hundreds of
packages can be built with a very simple (even one- or two-line)
.cygport script.  It may not be perfect, but IMNSHO it's far better than
the g-b-s was (not having used the latter for 2+ years).

Now there are some corner cases, and (obviously) with packages that I
don't maintain and probably never built.  When people bring these to my
attention, I try to find a solution that hopefully I and everyone else
can live with.  It may not be the proposed solution (and I know that's
been drives you nuts), but I need to be able to happy with the code
afterwards.

| I favor the boat-on-the-water model: go anywhere you want -- but if
| you're not careful you can run aground or drift too far out to sea. I
| figure the maintainers are all grown up, and can navigate their craft
| without help -- or restrictions -- from me.

Perhaps you're right about the core group of us, but there are always
new faces; I remember trying to tackle the g-b-s with my first ITP 4.5
years ago.  My goal is that cygport should be powerful enough to build
just about anything, yet be clean, simple, easy to learn, and easy to
maintain.

| I'll point out that 'postinst-doc' means, obviously, that you can
| customize only the post-installation-of-various-documents, and nothing
| else.  With a hook, the maintainer has maximum freedom -- to do things
| post-auto-install that neither you nor I have thought about -- but then
| he might get shipwrecked, too.

Then I suppose that I don't want to play Coast Guard. :-)

| ...the ultimate boat-on-the-water patch...

Which is why I'm not really convinced that it's necessary.


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

iEYEAREIAAYFAkgeO2AACgkQpiWmPGlmQSObEgCfbgg09CDZA4pmUuRp21lFxYu3
GggAoIdWNmDNepiH4yZtwvN3dqRlf17L
=L9sk
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/