This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH cygport] Add a command to make a test release

> Andrew Schulman writes:
> > Ooh, how about this:
> >
> >   cygport lftp.cygport all
> >   cygport lftp.cygport override curr=4.7.7-1 test=4.7.8-1
> >   cygport lftp.cygport up
> >
> > That would create override.hint and upload it with the package, leaving the
> > cygport file and source package alone.
> The command line parsing in cygport would become a lot more complicated
> for starters, so the syntax should be different.
> But more to the point, some people want to do this on the command line,
> while others do not.  I for one don't want to do it from the command
> line because I have oodles of packages that I build semi-automatically
> and changing the commands issued for each individual package just
> doesn't work well for me.  So I do want this to be part of the file set
> I commit to my Git repository instead (yes, if forced I could wrap
> another layer of scripting or cygport patches around it).  In other
> words, in the end we likely need to have both.

That's fine.

> A separate issue is if those things should end up in the package
> archives.  I agree that often they should not, so again my suggestion is
> to record this simply in a separate file that does not get packaged and
> (as outlined above) to provide means to create the same effects from the
> command line.

Agree. The idea is that cygport can create override.hint, or the packager can
create it. Then cygport uploads it along with the package files. But it's a
separate file, not part of the package archive.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]