[pacman-dev] Arch neutrral packages

newer
[pacman-dev] [BUG] pacman freezes...

Andrew Fyfe

9 Apr 2007 9 Apr '07

10:44 p.m.

Is it worth adding something like arch=(NOARCH) for packages that are arch neutral (ie they only contain text files, scripts...) so we don't have 2 identical packages for i686 and x86_64. Andrew

Show replies by date

Jeff 'codemac' Mickey

9 Apr 9 Apr

10:59 p.m.

* On Monday, April 09 2007, Andrew Fyfe wrote:

...

Is it worth adding something like arch=(NOARCH) for packages that are arch neutral (ie they only contain text files, scripts...) so we don't have 2 identical packages for i686 and x86_64.

Andrew

The PKGBUILD's would be the exact same, as a matter of fact, they would be built from the same source... And where do you suggest we put the arch neutral packages? current, current64 and currentNONE? I like the current setup, it minimizes complexity and is perfectly verbose. -- .: [ + carpe diem totus tuus + ] :.

Jason Chu

10 Apr 10 Apr

12:15 a.m.

On Mon, Apr 09, 2007 at 11:44:20PM +0100, Andrew Fyfe wrote:

...

Is it worth adding something like arch=(NOARCH) for packages that are arch neutral (ie they only contain text files, scripts...) so we don't have 2 identical packages for i686 and x86_64.

Andrew

There's been talk of this. I think it's a good idea. Apparently codemac thinks it's a bad idea. When I talked to phrakture about it a while back, his issue IIRC was that it's an arbitrary name and one day there might be a NOARCH architecture that we have to support... or something like that. Jason

Dan McGee

12:23 a.m.

On 4/9/07, Jason Chu wrote:

...

On Mon, Apr 09, 2007 at 11:44:20PM +0100, Andrew Fyfe wrote:

...
Is it worth adding something like arch=(NOARCH) for packages that are arch neutral (ie they only contain text files, scripts...) so we don't have 2 identical packages for i686 and x86_64.

Andrew

There's been talk of this. I think it's a good idea. Apparently codemac thinks it's a bad idea.

When I talked to phrakture about it a while back, his issue IIRC was that it's an arbitrary name and one day there might be a NOARCH architecture that we have to support... or something like that.

Jason

This is one of those ideas that the devil is in the details. I was thinking something like this a while back: arch=('all') Which would allow it to always be built, irregardless of the host type of the machine. This would only require reserving one keyword, "all". However, what does this allow us to do? Build a package called foo-1.0-1-all.pkg.tar.gz? I believe sync DB's can store the filename of the package, so this would work. However, unless we get rid of seperate directories for each architecture, this doesn't do much for us, besides save build time (which pacbuild will negate much of). In addition, I think hardcoding somewhere that 'all' means 'i686' and 'x86_64' is a terrible idea, as this ruins the idea of making adding architectures easy. We can't ever have a list of 'all' architectures. I guess I don't know exactly what it gains us by having an 'all', but if you can come up with a few scenarios, let me (and the list) know. -Dan

Jason Chu

12:59 a.m.

On Mon, Apr 09, 2007 at 08:23:56PM -0400, Dan McGee wrote:

...

On 4/9/07, Jason Chu wrote:

...
On Mon, Apr 09, 2007 at 11:44:20PM +0100, Andrew Fyfe wrote:

...
Is it worth adding something like arch=(NOARCH) for packages that are arch neutral (ie they only contain text files, scripts...) so we don't have 2 identical packages for i686 and x86_64.

Andrew

There's been talk of this. I think it's a good idea. Apparently codemac thinks it's a bad idea.

When I talked to phrakture about it a while back, his issue IIRC was that it's an arbitrary name and one day there might be a NOARCH architecture that we have to support... or something like that.

Jason

This is one of those ideas that the devil is in the details. I was thinking something like this a while back: arch=('all')

Which would allow it to always be built, irregardless of the host type ^^^^^^^^^^^^ You probably mean regardless...

http://dictionary.reference.com/browse/irregardless

...

of the machine. This would only require reserving one keyword, "all".

However, what does this allow us to do? Build a package called foo-1.0-1-all.pkg.tar.gz? I believe sync DB's can store the filename of the package, so this would work. However, unless we get rid of seperate directories for each architecture, this doesn't do much for us, besides save build time (which pacbuild will negate much of).

It saves us having to build the same package for N architectures when they all come out nearly identical. This saves time on the build machines (pacbuild and/or developer) and disk space on the mirrors. The more architectures we support, the more times we'll have to build the same package over and over.

...

In addition, I think hardcoding somewhere that 'all' means 'i686' and 'x86_64' is a terrible idea, as this ruins the idea of making adding architectures easy. We can't ever have a list of 'all' architectures.

Where would 'all' have to be "resolved"? What I mean to say is, in what places would you have to say "I have an 'all' package, which means that it's also valid for my architecture"? Or even better, when do we say, "what architectures can I install this package on?" Usually you go from architecture and look for stuff (pacman -S) or go from architecture to build (makepkg). Regarding having a list of 'all' architectures, we don't really need that. What architectures is 'all' not supported on? There's no list because 'all' is every supported architecture.

...

I guess I don't know exactly what it gains us by having an 'all', but if you can come up with a few scenarios, let me (and the list) know.

Jason

Roman Kyrylych

10:54 a.m.

I thought about arch="any" few times in the past. What's it useful for: fonts, icon themes, documentation packages, and one of the biggest things - game data (this would require splitting out *-data packages from big 3D games though). This will also save uploading time and server storage space. There are few technical issues: 1) Where to put those *-any (*-all whatever)? We have <repo>/os/<arch> structure, we can add <repo>/os/<any> too, but users that create mirror for one arch only shouldn't forget to sync "any" too. 2) How to store them in SCM? Well, with the last proposed /packages/package-name/PKGBUILD structure everything is simple as we won't have different dirs for each arch. 3) How to store them in repo DB? gensync/repo-add/etc. should handle arch="any" with every other arch at the same time, i.e. when updating i686 repo - add *-any packages to it too. -- Roman Kyrylych (Роман Кирилич)

Andrew Fyfe

12:26 a.m.

Jason Chu wrote:

...

On Mon, Apr 09, 2007 at 11:44:20PM +0100, Andrew Fyfe wrote:

...
Is it worth adding something like arch=(NOARCH) for packages that are arch neutral (ie they only contain text files, scripts...) so we don't have 2 identical packages for i686 and x86_64.

Andrew

There's been talk of this. I think it's a good idea. Apparently codemac thinks it's a bad idea.

When I talked to phrakture about it a while back, his issue IIRC was that it's an arbitrary name and one day there might be a NOARCH architecture that we have to support... or something like that.

Jason

------------------------------------------------------------------------

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

NOARCH was just the first thing that poped into my head, what about ALL. The reason I bring it up is if you're maintaining an arch neutral package you need to fudge CARCH everytime you want to build for the other archs. Andrew

6236

Age (days ago)

6237

Last active (days ago)

List overview

Download

6 comments

5 participants

participants (5)

Andrew Fyfe
Dan McGee
Jason Chu
Jeff 'codemac' Mickey
Roman Kyrylych