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

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

> - Do we have to change the RFU rules to include always the arch?
> 
>   If we change the naming convention of packages to include the arch,
>   probably not.

Or if we make cygport organize things as above.


Yaakov


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