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: Release directories (was Re: [PATCH] setup: port to 64-bit, part 1)

On Thu, 14 Mar 2013 10:57:57 -0400, Christopher Faylor wrote:
> On Thu, Mar 14, 2013 at 10:41:47AM +0100, Corinna Vinschen wrote:
> >On Mar 13 21:01, Yaakov wrote:
> >> On Wed, 13 Mar 2013 12:51:18 +0100, Corinna Vinschen wrote:
> >> > If Yaakov applied the changes necessary to get the 64 bit setup running
> >> > for a start, would it be possible to let upset create a setup64.ini file
> >> > for the current cygwin/64bit/release test area?
> >> 
> >> Before we do that, I think we need to consider a bit of
> >> reorganization.  As in any binary distribution, there are many "noarch"
> >> packages which could be used for both i686 and x86_64.  Providing two
> >> identical copies is just a waste of storage and bandwidth for
> >> sourceware, mirrors, and users.
> >> 
> >> Instead, I think it would make sense to make three sibling trees, one
> >> for i686 (the current release/ directory), one for x86_64, and one for
> >> noarch packages.  Then, there would be two scans by upset: setup.ini
> >> from i686 and noarch, and setup64.ini from x86_64 and noarch.
> >> 
> >> Thoughts?
> >
> >Yes.  You're right of course.  This problem raises a few questions.
> I understand the desire to only store things once but I think this
> would end up being a bookkeeping nightmare and, while other distros
> do have a "noarch" designation they don't, AFAIK, store noarch packages
> in a separate location.  They are mixed with the rest of the packages.
> I just checked the Fedora distro to verify that this was the case and
> I see, for instance: asterisk-sounds-core-en-1.4.22-1.el6.noarch.rpm
> It exists in two separate places in the repo.
> The other problem with noarch packages is that it means that the 64 and
> 32 bit releases will need to be in lock step.  Otherwise a noarch package
> which relies on a 64-bit package (or vice-versa) will require an update
> for the 32 bit package at the same time.  That means that you can't release
> the 64-bit version on Monday and the 32-bit version on Tuesday.

Isn't keeping the two arches in lock step a desirable goal?


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