[arch-general] Does pacman support "noarch" now? - Arch-general - lists.archlinux.org

newer
Re: [arch-general]...

[arch-general] Does pacman support "noarch" now?

older
[arch-general] makepkg running as...

甘露

23 Jan 2008 23 Jan '08

5:17 a.m.

All fonts do not need a "i686" or "x86_64" option but in my memory pacman doesn't support noarch, which makes PKGBUILDs for fonts unable to compile without a unnecessary line. Thanks.

Show replies by date

Attila

23 Jan 23 Jan

6:45 a.m.

On Mittwoch, 23. Januar 2008 06:17 ?? wrote:

All fonts do not need a "i686" or "x86_64" option but in my memory pacman doesn't support noarch, which makes PKGBUILDs for fonts unable to compile without a unnecessary line.

The NEWS link from http://www.archlinux.org/pacman says: - arch=('any') support (FS#8153) See you, Attila

Mark Constable

7:46 a.m.

On 23 Jan 2008 16:45, Attila wrote:

...
All fonts do not need a "i686" or "x86_64" option but in my memory pacman doesn't support noarch, which makes PKGBUILDs for fonts unable to compile without a unnecessary line.

The NEWS link from http://www.archlinux.org/pacman says:

- arch=('any') support (FS#8153)

It's mentioned in the NEWS file and that bug report is very brief so where might the information be on how to actually implement the use of arch=('any') ? The one thing I can glean is that any 'any' packages will be added to all arch databases rather than have a separate directory tree for 'any' arch packages with it's own DB. --markc

Roman Kyrylych

9:46 a.m.

2008/1/23, Mark Constable :

On 23 Jan 2008 16:45, Attila wrote:

...
...
All fonts do not need a "i686" or "x86_64" option but in my memory pacman doesn't support noarch, which makes PKGBUILDs for fonts unable to compile without a unnecessary line.

The NEWS link from http://www.archlinux.org/pacman says:

- arch=('any') support (FS#8153)

It's mentioned in the NEWS file and that bug report is very brief so where might the information be on how to actually implement the use of arch=('any') ?

The one thing I can glean is that any 'any' packages will be added to all arch databases rather than have a separate directory tree for 'any' arch packages with it's own DB.

It's not yet implemented on a server side. I'm working on it (though not as fast as I'd wish). You can get more information about this on arch-dev-public archives. -- Roman Kyrylych (Роман Кирилич)

Mark Constable

12:53 p.m.

On 23 Jan 2008 19:46, Roman Kyrylych wrote:

It's not yet implemented on a server side. I'm working on it (though not as fast as I'd wish). You can get more information about this on arch-dev-public archives.

I skimmed the subjects back to November and found some references to pacman 3.1.0 and then 3.1.1 but they were all mainly signoffs and no info or discussion about how to use arch=('any') (that I could find after an hour). http://archlinux.org/mailman/listinfo/arch-dev-public I've read through the man pages for pacman, libalpm, pacman.conf, makepkg and the README in the src so any clues from anyone how to use arch=('any') would be appreciated. --markc

Roman Kyrylych

1:23 p.m.

2008/1/23, Mark Constable :

On 23 Jan 2008 19:46, Roman Kyrylych wrote:

...
It's not yet implemented on a server side. I'm working on it (though not as fast as I'd wish). You can get more information about this on arch-dev-public archives.

I skimmed the subjects back to November and found some references to pacman 3.1.0 and then 3.1.1 but they were all mainly signoffs and no info or discussion about how to use arch=('any') (that I could find after an hour).

http://archlinux.org/mailman/listinfo/arch-dev-public

I've read through the man pages for pacman, libalpm, pacman.conf, makepkg and the README in the src so any clues from anyone how to use arch=('any') would be appreciated.

Things that work now: * makepkg support to understand arch=('any') and build a package correctly * repo-add/repo-remove work too, so you can create a db with them and test how pacman installs those packages. * pacman should pring 'Architecture: any' on -Si/-Qi Note that repo-add/repo-remove and pacman didn't require a single change to support '-any' packages, that's because they don't care about packages' architecture. Packages produced from PKGBUILD with arch=('any') are _excactly_ same when built on either i686 or x86_64 or even unofficial 'i586' and 'ppc' (when built with makepkg >= 3.0). (They can differ only by build timestamp) Right now, '-any' packages cannot be used in AUR and official repos yet. You may use them for your own local repo for arch-independent packages if you have both i686 and x86_64 installed. Be sure to add '-any' to both i686 and x86_64 localrepo.db.tar.gz files when updating your repo db. -- Roman Kyrylych (Роман Кирилич)

Dan McGee

2:20 p.m.

On Jan 23, 2008 7:23 AM, Roman Kyrylych wrote:

Packages produced from PKGBUILD with arch=('any') are _excactly_ same when built on either i686 or x86_64 or even unofficial 'i586' and 'ppc' (when built with makepkg >= 3.0). (They can differ only by build timestamp)

ONLY if they are architecture independent packages in the first place, so watch out here. That statement was a bit too general. -Dan

Jan de Groot

2:57 p.m.

-----Oorspronkelijk bericht----- Van: arch-general-bounces@archlinux.org [mailto:arch-general- bounces@archlinux.org] Namens Dan McGee Verzonden: woensdag 23 januari 2008 15:20 Aan: General Discusson about Arch Linux Onderwerp: Re: [arch-general] Does pacman support "noarch" now?

On Jan 23, 2008 7:23 AM, Roman Kyrylych wrote:

...
Packages produced from PKGBUILD with arch=('any') are _excactly_ same when built on either i686 or x86_64 or even unofficial 'i586' and 'ppc' (when built with makepkg >= 3.0). (They can differ only by build timestamp)

ONLY if they are architecture independent packages in the first place, so watch out here. That statement was a bit too general.

-Dan

This includes java applications like eclipse-ecj, bcprov, azureus, etc. It excludes java programs with native interfaces like swt and eclipse though.

Roman Kyrylych

4:26 p.m.

2008/1/23, Dan McGee :

On Jan 23, 2008 7:23 AM, Roman Kyrylych wrote:

...
Packages produced from PKGBUILD with arch=('any') are _excactly_ same when built on either i686 or x86_64 or even unofficial 'i586' and 'ppc' (when built with makepkg >= 3.0). (They can differ only by build timestamp)

ONLY if they are architecture independent packages in the first place, so watch out here. That statement was a bit too general.

Thanks for making this bold, as my words indeed were not very well said. -- Roman Kyrylych (Роман Кирилич)

Mark Constable

3:34 p.m.

On 23 Jan 2008 23:23, Roman Kyrylych wrote:

Things that work now: * makepkg support to understand arch=('any') and build a package correctly * repo-add/repo-remove work too, so you can create a db with them and test how pacman installs those packages. * pacman should pring 'Architecture: any' on -Si/-Qi Note that repo-add/repo-remove and pacman didn't require a single change to support '-any' packages, that's because they don't care about packages' architecture.

Right, so they are arch agnostic, cool.

Packages produced from PKGBUILD with arch=('any') are _excactly_ same when built on either i686 or x86_64 or even unofficial 'i586' and 'ppc' (when built with makepkg >= 3.0). (They can differ only by build timestamp)

Right now, '-any' packages cannot be used in AUR and official repos yet. You may use them for your own local repo for arch-independent packages if you have both i686 and x86_64 installed.

Why the requirement for both "i686 and x86_64 installed" ?

Be sure to add '-any' to both i686 and x86_64 localrepo.db.tar.gz files when updating your repo db.

I know this is not the right way to do it but it's a first attempt to get a feel for how to do it properly... I have built an -any package and uploaded it into it's own area with it's own [repo] stanza and successfully added that same package to both an i686 and x86_64 system. I could not do this pre v3 pacman with i868 or x86_64 in the filename. What I am unsure of is, in this example, how to add the -any package to both 32bit and 64bit *.db.tar.gz files so that the -any package, in a different area, can still be downloaded... ie; will relative paths work ? I've added this to my /etc/pacman.conf, uncommenting the appropriate arch on either machine... [proaudio-any] Server = http://pkg.markconstable.com/proaudio/any #[proaudio-i32] #Server = http://pkg.markconstable.com/proaudio/i32 #[proaudio-i64] #Server = http://pkg.markconstable.com/proaudio/i64 -------------------------------------------------------------- # pacman -S fluidr3 resolving dependencies... looking for inter-conflicts... Targets: fluidr3-122501-2 [125.73 MB] Total Download Size: 125.73 MB Total Installed Size: 141.53 MB Proceed with installation? [Y/n] :: Retrieving packages from proaudio-any... fluidr3-122501-2-any 125.7M 89.2K/s 00:24:03 [...] 100% checking package integrity... (1/1) checking for file conflicts [...] 100% (1/1) upgrading fluidr3 [...] 100%

...
...
Add this line in your /etc/timidity++/timidity.cfg file to enable this soundfont :

soundfont /usr/share/soundfonts/fluidr3/FluidR3GM.SF2

--markc

Dan McGee

4 p.m.

On Jan 23, 2008 9:34 AM, Mark Constable wrote:

I know this is not the right way to do it but it's a first attempt to get a feel for how to do it properly... I have built an -any package and uploaded it into it's own area with it's own [repo] stanza and successfully added that same package to both an i686 and x86_64 system. I could not do this pre v3 pacman with i868 or x86_64 in the filename.

What I am unsure of is, in this example, how to add the -any package to both 32bit and 64bit *.db.tar.gz files so that the -any package, in a different area, can still be downloaded... ie; will relative paths work ?

I'm not sure, to be honest. I doubt it, as relative paths would lock people into having the same repository layout if it is mirrored. Your best bet is probably to set up some symlinks/hardlinks to the appropriate places, which should do the job. -Dan

Roman Kyrylych

4:24 p.m.

2008/1/23, Mark Constable :

On 23 Jan 2008 23:23, Roman Kyrylych wrote:

...
Things that work now: * makepkg support to understand arch=('any') and build a package correctly * repo-add/repo-remove work too, so you can create a db with them and test how pacman installs those packages. * pacman should pring 'Architecture: any' on -Si/-Qi Note that repo-add/repo-remove and pacman didn't require a single change to support '-any' packages, that's because they don't care about packages' architecture.

Right, so they are arch agnostic, cool.

...
Packages produced from PKGBUILD with arch=('any') are _excactly_ same when built on either i686 or x86_64 or even unofficial 'i586' and 'ppc' (when built with makepkg >= 3.0). (They can differ only by build timestamp)

Right now, '-any' packages cannot be used in AUR and official repos yet. You may use them for your own local repo for arch-independent packages if you have both i686 and x86_64 installed.

Why the requirement for both "i686 and x86_64 installed" ?

It's not a requirement, of course. IMO that just don't make much difference to change arch=() in every arch-indepent package you build from AUR if you use only one arch.

...
Be sure to add '-any' to both i686 and x86_64 localrepo.db.tar.gz files when updating your repo db.

I know this is not the right way to do it but it's a first attempt to get a feel for how to do it properly... I have built an -any package and uploaded it into it's own area with it's own [repo] stanza and successfully added that same package to both an i686 and x86_64 system. I could not do this pre v3 pacman with i868 or x86_64 in the filename.

What I am unsure of is, in this example, how to add the -any package to both 32bit and 64bit *.db.tar.gz files so that the -any package, in a different area, can still be downloaded... ie; will relative paths work ?

Symlinks (or maybe hardlinks) Example: /mylocalrepo/any/foobar-1.0-1-any.pkg.tar.gz <- the real file /mylocalrepo/i686/foobar-1.0-1-any.pkg.tar.gz -> ../any/foobar-1.0-1-any.pkg.tar.gz /mylocalrepo/x86_64/foobar-1.0-1-any.pkg.tar.gz -> ../any/foobar-1.0-1-any.pkg.tar.gz Then you just do 'repo-add mylocalrepo.db.tar.gz *' in i686 and x86_64 trees.

I've added this to my /etc/pacman.conf, uncommenting the appropriate arch on either machine...

[proaudio-any] Server = http://pkg.markconstable.com/proaudio/any

#[proaudio-i32] #Server = http://pkg.markconstable.com/proaudio/i32

#[proaudio-i64] #Server = http://pkg.markconstable.com/proaudio/i64

This looks a bit ugly on users side and doubles the number of repositories. Besides, Pacman keeps track of groups only in one repo, so when you do pacman -Sg gnome-extra you'll get one list of packages in extra and then another list of packages in extra-any (e.g. gnome-audio) Moreover, if you have testing repo at the end and want to test some new package - you do -S testing/pkgname but now with *-any repos you'll have to remember if that package arch-dependent or not. To summarize - while it seems easier on server side - it just brings more problems and no benefit on users side. -- Roman Kyrylych (Роман Кирилич)

Mark Constable

4:56 p.m.

On 24 Jan 2008 02:24, Roman Kyrylych wrote:

...
[proaudio-any] Server = http://pkg.markconstable.com/proaudio/any

#[proaudio-i32] #Server = http://pkg.markconstable.com/proaudio/i32

#[proaudio-i64] #Server = http://pkg.markconstable.com/proaudio/i64

This looks a bit ugly on users side and doubles the number of repositories. ... To summarize - while it seems easier on server side - it just brings more problems and no benefit on users side.

Okay, the user side wins so I will go with using symlinks. Roman, thank you very much for your guidance, much appreciated. --markc

5955

Age (days ago)

5955

Last active (days ago)

Download

12 comments

6 participants

tags

participants (6)

Attila
Dan McGee
Jan de Groot
Mark Constable
Roman Kyrylych
甘露