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 Mar 14 10:57, 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.

That's a good point.  Let's assume that disk space is no issue here, but
what about uploading?  For noarch packages you have to think of copying
the file to two dirs by default.  We're just human, so...

I guess in the long run it would be positive to switch to an entirly
script based uploading mechanism, or even a way which allows every
maintainer to upload the own packages.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat


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