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 04:54, Yaakov wrote:
> On Thu, 14 Mar 2013 10:41:47 +0100, Corinna Vinschen wrote:
> > On Mar 13 21:01, Yaakov wrote:
> > > 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.
> > 
> > Yes.  You're right of course.  This problem raises a few questions.
> > 
> > - How do we store the packages on sourceware?
> > 
> >   Probably the easiest is to split into three dirs, as you suggested.
> >   The naming is pretty irrelevant, but it might be best to use a
> >   target name as the directory base, as on Linux:
> [snip]
> >   Alternatively we could stick to the current "release" name for the
> >   i686 distro and use only new, parallel dirs for noarch and new targets:
> The former option may be easier to incorporate into cygport (e.g.
> release/$ARCH/$NAME instead of dist/$NAME, and maybe a
> user-configurable location for that release folder where all packages
> would land).  The latter option would be less of a burden on sourceware,
> since only some of the packages would be moving instead of all of them.

Well, I don't mind.  If you add a symlink release.i686 -> release, you
would have an unambiguous naming scheme as well.  However, we already
had this discussion when we switched from 1.5 to 1.7.  If the one time
mirror load is no argument, we can easily switch to layout 1.

> >   Another problem is to move the existing noarch packages into the
> >   right dir when we start.  Well, at least this only has to be done
> >   once, baring any mistakes.
> > 
> > - For uploading packages it's important to know where the new package
> >   has to go.  Therefore, IMHO, it would make sense to change to a new
> >   package naming scheme, preferedly compatible with the versioning
> >   mechanism in upset, supported by cygport and easily recognizable by
> >   uploaders or upload scripts.
> > 
> >   Linux distros typically use the architecture after the version number:
> > 
> >     package-foo-1.2.3-4.i686.tar.bz2
> >     package-bar-5-6-7.noarch.tar.bz2
> > 
> >   However, for backward compatiblity with the current mechanism, would it
> >   make sense to reorder it for Cygwin packages like so:
> > 
> >     package-foo-i686-1.2.3-4.tar.bz2
> >     package-bar-noarch-5.6-7.tar.bz2
> Nack.  IIUC this form would confuse upset/setup/cygcheck to no end.

And the first form wouldn't?  I would love to see this form used,
but I was actually thinking this would result in more confusion...


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]