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: Mismatch [1.5] [1.7]: lzip-1.8-1

JonY wrote:
> On 11/22/2009 12:17, Eric Blake wrote:

>> Release a single -2 for just one of the two versions (your choice of 
>> whether it is for 1.5 or for 1.7); but do NOT do a -2 for both 1.5 and 
>> 1.7, or we are right back to the complaint. In future builds, if you want
>>  to continue supporting both 1.5 and 1.7, be sure that the numbering for 
>> 1.5 is different than the numbering for 1.7. That way, when someone asks 
>> about -1, you can unambiguously determine for which version of cygwin 
>> they are asking about.
> Hi,
> Good point, I haven't thought of that. I've sent -2 for 1.7 to cygwin-apps.
> Perhaps somebody should add a hint to packaging guide at
> <> about maintaining packages for 2 or more
> versions of Cygwin.

  I'd be glad if someone would do this too, but it can't be me, because I
really haven't a scooby what's wrong with having the same version number in
separate 1.5 and 1.7 builds.  I may have overlooked something here, but I
can't even imagine a reason why Fergus was comparing packages between the
release and release-2 trees in the first place.

  Eric's suggestion above that it could act as a heuristic to tell you what
version of cygwin is in play doesn't seem like an argument from necessity to
me, because you can always unambiguously determine which version of cygwin is
in use by asking the poster or reading their cygcheck output.

  If you build and package exactly the same sources in exactly the same way
under 1.5 and 1.7, I would by default expect them to be released with the same
version numbers.  Nothing is actually going to conflict, is it?

  I also thought that one of the main reasons we were using a union-fs was so
that we'd get shadows of the existing packages by default but could diverge
them where we wanted to; otherwise we could just have one release tree which
both setup.ini and setup-2.ini point into, each only listing their own
relevant packages?

  Note that this is not just a theoretical concern for me, I've already rolled
a gcc4-4.3.4-2 that just needs some testing, but now it seems I may have to
respin it (or perhaps drop the 1.5 version I was planning, but that's a topic
for another thread.)


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