cygport improvements: upload, fish, src_prep_fini_hook

Andrew Schulman
Wed Dec 10 23:05:00 GMT 2014

> > The point of having an upload command
> > is to relieve packagers of the tedium and likelihood of getting it wrong
> > when they have to remember where to connect to and which commands to run to
> > put what files where.  How much nicer to just run "cygport up" and let
> > cygport handle it.
> It then does not in fact work correctly when you're uploading from more
> than a single cygport file that depend on each other.

I guess this is a limitation of cygport.  cygport always only works with
one cygport file at a time, in each invocation.  So no, it won't look
around to find required packages built from different cygport files and
upload them too/first, if that's what you mean.

If you're talking about the case of multiple packages being built from one
cygport file and one source archive, yes, it does handle that case
> I frequently build multiple packages (in the case of Perl that means
> tens to hundreds depending on whether I do a full rebuild or just
> updates) and there's no way I'm ever going to upload anything directly
> from the build machine to  So what you're implementing isn't
> useful in that situation for me.  I'll just patch cygport to link the
> dist directories into my local mirror structure then.

Hm. OK.  That sounds like an unusual case to me, but I guess it might make
sense to add a variable to allow uploading to some place other than  It could get into some work to deal with upload methods for
different URL schemes, though.  I'm still struggling a bit with sftp.

> > * !ready will only be created after all of the files have been successfully
> > uploaded.  If there's an error during the upload, it's not created.
> There is only a single cygport file handled for each invocation.

Yes.  But if there are multiple resulting packages, they're all uploaded
together, then !ready is created.

> > * The current implementation puts the !ready file into a package-specific
> > directory, e.g. /x86_64/screen, instead of /x86_64.  So by running "cygport
> > up" you only flag a single package as ready, not the whole arch directory.
> That is better, but still doesn't handle the case where dependencies
> across packages change.  That is admittedly rare, but it's a limitation
> of what you're implementing.

Yes it is, since it doesn't handle dependencies across packages with
different cygport files at all.  Just one cygport file at a time, and the
one or more packages that are built from it.


More information about the Cygwin-apps mailing list