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

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

[Jon Turney]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]


This patch (originally by Achim Gratz) adds a mechanism for generating 
packages marked as 'test' as described in [1].

I'm not committed to any of the details, but I would like to get 
something with this functionality in, so tell me how you'd like it 
implemented and I'll do it...

[1] https://cygwin.com/ml/cygwin-apps/2016-12/msg00005.html

[-- Attachment #2: 0001-Add-a-command-to-make-a-test-release.patch --]
[-- Type: text/plain, Size: 3360 bytes --]

From f0e8ed8266da36fcf5ea0b648e91c1be5e793c6b Mon Sep 17 00:00:00 2001
From: Achim Gratz <Stromeko@Stromeko.DE>
Date: Sat, 8 Apr 2017 17:00:34 +0200
Subject: [PATCH cygport] Add a command to make a test release

lib/pkg_pkg.cygpart: inform when creating hint files for a test release.

lib/help.cygport: document command to package test releases.

bin/cygport.in: provide command to package test releases.

v2:
Add test: to all hints
Add to help output

Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
---
 bin/cygport.in      |  3 +++
 lib/help.cygpart    |  1 +
 lib/pkg_pkg.cygpart | 13 +++++++++++++
 3 files changed, 17 insertions(+)

diff --git a/bin/cygport.in b/bin/cygport.in
index 6cf0122..9cf6f46 100644
--- a/bin/cygport.in
+++ b/bin/cygport.in
@@ -599,6 +599,9 @@ do
 			__show_web;
 			_status=$?;
 			;;
+		package-test|pkg-test)
+			TESTRELEASE=cmdline;
+			;&
 		package|pkg)
 			__stage Packaging;
 			__log_init ${pkglog};
diff --git a/lib/help.cygpart b/lib/help.cygpart
index 460f8f7..54819a9 100644
--- a/lib/help.cygpart
+++ b/lib/help.cygpart
@@ -46,6 +46,7 @@ __show_help() {
 		  test         run the package's test suite, if one exists
 		  install      install into a DESTDIR, and run post-installation steps
 		  package      create binary and source packages
+		  package-test create binary and source packages, marked as test
 		  upload       upload finished packages to cygwin.com
 		  announce     send an announcement email to cygwin.com
 		  finish       delete the working directory
diff --git a/lib/pkg_pkg.cygpart b/lib/pkg_pkg.cygpart
index cfc0770..c3b47fe 100644
--- a/lib/pkg_pkg.cygpart
+++ b/lib/pkg_pkg.cygpart
@@ -665,6 +665,14 @@ __pkg_dist() {
 #  libfoo-devel will use libfoo_devel_OBSOLETES.
 #****
 
+	pkg_testrelease=${TESTRELEASE+test:};
+	if [ "test:" = "${pkg_testrelease:-none}" ]
+	then
+		inform "Package hint files are prepared for a \e[1;31mtest\e[0;0m release\n"
+	else
+		inform "Package hint files are prepared for a \e[1;32mcurrent\e[0;0m release\n"
+	fi
+
 	n=0;
 	while defined pkg_name[${n}]
 	do
@@ -712,6 +720,7 @@ category: ${!pkg_category_var:-${CATEGORY}}
 requires: ${pkg_bin_requires} ${!pkg_requires_var}
 sdesc: "${!pkg_summary_var:-${SUMMARY}}"
 ldesc: "${!pkg_description_var:-${DESCRIPTION:-${!pkg_summary_var:-${SUMMARY}}}}"
+${pkg_testrelease}
 _EOF
 			if defined distsubdir
 			then
@@ -751,6 +760,7 @@ ldesc: "The ${obspkg} package is obsolete.  Selecting this package for
 installation will cause the ${pkg_name[${n}]} package, which replaces this
 one, to be installed instead."
 ${obssubdir:+external-source: ${PN}}
+${pkg_testrelease}
 _EOF
 		done
 
@@ -777,6 +787,7 @@ external-source: ${PN}
 sdesc: "Debug info for ${PN}"
 ldesc: "This package contains files necessary for debugging the
 ${PN} package with gdb."
+${pkg_testrelease}
 _EOF
 		fi
 
@@ -795,6 +806,7 @@ ldesc: "The ${obspkg} package is obsolete.  Selecting this package for
 installation will cause the ${PN}-debuginfo package, which replaces this
 one, to be installed instead."
 external-source: ${PN}
+${pkg_testrelease}
 _EOF
 		done
 	fi
@@ -820,6 +832,7 @@ category: ${!pkg_category_var:-${CATEGORY}}
 requires:
 sdesc: "${!pkg_summary_var:-${SUMMARY}}"
 ldesc: "${!pkg_description_var:-${DESCRIPTION:-${!pkg_summary_var:-${SUMMARY}}}}"
+${pkg_testrelease}
 skip:
 _EOF
 		else
-- 
2.14.2

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

[Andrew Schulman]

> 
> This patch (originally by Achim Gratz) adds a mechanism for generating 
> packages marked as 'test' as described in [1].
> 
> I'm not committed to any of the details, but I would like to get 
> something with this functionality in, so tell me how you'd like it 
> implemented and I'll do it...
> 
> [1] https://cygwin.com/ml/cygwin-apps/2016-12/msg00005.html

Cygport needs a way to specify which versions are prev, curr, and test in
cygport files. David Rothenberger and I each proposed a method [1,2]. It
doesn't matter much to me which method is picked, but it's definitely a
missing feature.

[1]https://sourceware.org/ml/cygwin-apps/2013-06/msg00032.html
[2]https://sourceware.org/ml/cygwin-apps/2015-06/msg00038.html

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

[Achim Gratz]

Andrew Schulman writes:
> Cygport needs a way to specify which versions are prev, curr, and test in
> cygport files. David Rothenberger and I each proposed a method [1,2]. It
> doesn't matter much to me which method is picked, but it's definitely a
> missing feature.

My latest iteration on the original patch by David:

http://repo.or.cz/cygport/rpm-style.git/commitdiff/b169fec0a4a14e79a1d07bd0df300ef1f43b92a0


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

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

[Jon Turney]

On 03/10/2017 21:01, Andrew Schulman wrote:
>> This patch (originally by Achim Gratz) adds a mechanism for generating
>> packages marked as 'test' as described in [1].
>>
>> I'm not committed to any of the details, but I would like to get
>> something with this functionality in, so tell me how you'd like it
>> implemented and I'll do it...
>>
>> [1] https://cygwin.com/ml/cygwin-apps/2016-12/msg00005.html
> 
> Cygport needs a way to specify which versions are prev, curr, and test in
> cygport files. David Rothenberger and I each proposed a method [1,2]. It
> doesn't matter much to me which method is picked, but it's definitely a
> missing feature.

I'm not keen on the idea of including this transient information into 
the cygport, and thus baking it into the source package.

However, I also want to make package maintainers lives easier.  So, I'm 
all for automation to make things less tedious and error-prone, which 
this patch attempts to do.

A few points to consider:

* I'm going to remove the restriction that you can only have 3 versions. 
(I keep on putting this off only because it will break parsing setup.ini 
for setup prior to 2.877)

* (This also means that more than one test: version may be available)

* Changing curr: doesn't cause setup to downgrade (since 2.864) (unless 
--force-current is used, since 2.874)

* prev: isn't a very significant label, since the only way to install 
that version is by manually selecting it, i.e. all it means is "keep 
this version around"

Taking a step back, as a package maintainer, what do you need to 
control?  What features do we need here?

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

[Andrew Schulman]

> On 03/10/2017 21:01, Andrew Schulman wrote:
> >> This patch (originally by Achim Gratz) adds a mechanism for generating
> >> packages marked as 'test' as described in [1].
> >>
> >> I'm not committed to any of the details, but I would like to get
> >> something with this functionality in, so tell me how you'd like it
> >> implemented and I'll do it...
> >>
> >> [1] https://cygwin.com/ml/cygwin-apps/2016-12/msg00005.html
> > 
> > Cygport needs a way to specify which versions are prev, curr, and test in
> > cygport files. David Rothenberger and I each proposed a method [1,2]. It
> > doesn't matter much to me which method is picked, but it's definitely a
> > missing feature.
> 
> I'm not keen on the idea of including this transient information into 
> the cygport, and thus baking it into the source package.
> 
> However, I also want to make package maintainers lives easier.  So, I'm 
> all for automation to make things less tedious and error-prone, which 
> this patch attempts to do.
> 
> A few points to consider:
> 
> * I'm going to remove the restriction that you can only have 3 versions. 
> (I keep on putting this off only because it will break parsing setup.ini 
> for setup prior to 2.877)
> 
> * (This also means that more than one test: version may be available)
> 
> * Changing curr: doesn't cause setup to downgrade (since 2.864) (unless 
> --force-current is used, since 2.874)
> 
> * prev: isn't a very significant label, since the only way to install 
> that version is by manually selecting it, i.e. all it means is "keep 
> this version around"
> 
> Taking a step back, as a package maintainer, what do you need to 
> control?  What features do we need here?

Thanks. 

Most commonly, I just want to make a version test, which this patch allows.

Sometimes more complicated situations come up. We have one with lftp right now:

prev: 4.7.7-1
curr: 4.8.0-1
test: 4.7.8-1

This happened because 4.8.0-1 turns out to be broken, and later versions won't
build in Cygwin yet. So I had to promote 4.7.8-1 to test. Assuming it's okay,
shortly I want to promote it to current and dump 4.8.0-1, leaving

prev: 4.7.7-1
curr: 4.7.8-1

I can do this by creating an override.hint file, but right now I have to upload
that manually. It'd be nice if I could tell cygport to handle it, in whatever
way is best.

I think it's fine to put the prev, curr, and test instructions in the cygport
file, and have it create and upload the override.hint. cygport files already
have version information in them (VERSION, RELEASE). 

But if you don't like that, we could ask maintainers to create override.hint
files separately, and just have cygport recognize and upload those. That's fine
too, as long as there's a way to allow different override.hint files by arch,
which is bound to be needed sometimes.

Andrew

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

[Ken Brown]

On 10/5/2017 10:23 AM, Andrew Schulman wrote:
> Sometimes more complicated situations come up. We have one with lftp right now:
> 
> prev: 4.7.7-1
> curr: 4.8.0-1
> test: 4.7.8-1
> 
> This happened because 4.8.0-1 turns out to be broken, and later versions won't
> build in Cygwin yet. So I had to promote 4.7.8-1 to test.

I didn't pay close attention to the lftp bug reports, so what I'm saying 
may be nonsense.  But wouldn't it make more sense to just remove 4.8.0-1 
if it's broken?  You could still make 4.7.8-1 a test version, leaving a 
working 4.7.7-1 as current.

Doing it this way, you wouldn't need anything but the ability to mark a 
release as "test".

Ken

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

[Achim Gratz]

Jon Turney writes:
> I'm not keen on the idea of including this transient information into
> the cygport, and thus baking it into the source package.

Fair enough.  If that's the only thing that bothers you, this
information could easily live in some extra file that doesn't get
packaged.  Deal?

> However, I also want to make package maintainers lives easier.  So,
> I'm all for automation to make things less tedious and error-prone,
> which this patch attempts to do.

I plan to modify the patch for test versions so that it automatically
produces one if the release starts with "0".  Thoughts?

> * I'm going to remove the restriction that you can only have 3
> versions. (I keep on putting this off only because it will break
> parsing setup.ini for setup prior to 2.877)

HOw about for after we roll in libsolv and move to setup-3.x?

> * (This also means that more than one test: version may be available)

That seems awkward to handle.

> * Changing curr: doesn't cause setup to downgrade (since 2.864)
> (unless --force-current is used, since 2.874)

We need to eventually solve that problem in a different way, I think.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

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

[Achim Gratz]

Andrew Schulman writes:
> This happened because 4.8.0-1 turns out to be broken, and later versions won't
> build in Cygwin yet. So I had to promote 4.7.8-1 to test. Assuming it's okay,
> shortly I want to promote it to current and dump 4.8.0-1, leaving
>
> prev: 4.7.7-1
> curr: 4.7.8-1

Again, that won't automatically install 4.7.8 for anyone who already
upgraded to 4.8.0 (unless the --force-current switch is given).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

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

[cyg Simple]

On 10/5/2017 2:16 PM, Achim Gratz wrote:
> Andrew Schulman writes:
>> This happened because 4.8.0-1 turns out to be broken, and later versions won't
>> build in Cygwin yet. So I had to promote 4.7.8-1 to test. Assuming it's okay,
>> shortly I want to promote it to current and dump 4.8.0-1, leaving
>>
>> prev: 4.7.7-1
>> curr: 4.7.8-1
> 
> Again, that won't automatically install 4.7.8 for anyone who already
> upgraded to 4.8.0 (unless the --force-current switch is given).
> 

This won't solve the current issue but shouldn't --force-current be the
default?  Maybe could be suggested in the hint file with another line
similar to:

force_curr: true

or

force: 4.7.8-1

-- 
cyg Simple

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

[Andrew Schulman]

> On 10/5/2017 10:23 AM, Andrew Schulman wrote:
> > Sometimes more complicated situations come up. We have one with lftp right now:
> > 
> > prev: 4.7.7-1
> > curr: 4.8.0-1
> > test: 4.7.8-1
> > 
> > This happened because 4.8.0-1 turns out to be broken, and later versions won't
> > build in Cygwin yet. So I had to promote 4.7.8-1 to test.
> 
> I didn't pay close attention to the lftp bug reports, so what I'm saying 
> may be nonsense.  But wouldn't it make more sense to just remove 4.8.0-1 
> if it's broken? 

Maybe. It was partly broken.

> You could still make 4.7.8-1 a test version, leaving a 
> working 4.7.7-1 as current.
> 
> Doing it this way, you wouldn't need anything but the ability to mark a 
> release as "test".

No, it also requires the ability to remove 4.8.0-1. To do that I have to
either ask for help here, or upload an override.hint file with

curr: 4.7.7-1
test: 4.7.8-1

or

prev: 4.7.7-1
curr: 4.7.8-1

So it'd be nice if cygport could do that for me.

Obviously this is an unusual case, but every now and then for one reason or
another I need to upload an override.hint file. Any time I do that, it'd be
nice if cygport handled the details for me.

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.

Andrew

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

[Achim Gratz]

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.

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.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

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

[Andrew Schulman]

> 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.

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

[Yaakov Selkowitz]

[-- Attachment #1.1: Type: text/plain, Size: 462 bytes --]

On 2017-10-03 14:51, Jon Turney wrote:
> This patch (originally by Achim Gratz) adds a mechanism for generating
> packages marked as 'test' as described in [1].
> 
> I'm not committed to any of the details, but I would like to get
> something with this functionality in, so tell me how you'd like it
> implemented and I'll do it...

https://github.com/cygwinports/cygport/commit/515fc7caa1ccfd8ce3e67deeb6667be481f56e42

Please test.

-- 
Yaakov


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]