[arch-ports] developing the (arch64) port

[Cam Daniel]

Andreas Radke wrote:
> On the port side:
> 
> - All arch64 developers should read this:
> http://dev.gentoo.org/~plasmaroo/devmanual/archs/amd64/
> "Applying |-fPIC| on all objects will slow down the binaries in a
> drastic way."
> So I will drop it again from the default CFLAGS. A new pacman package is
> needed. I'll do this later when we are sure how the future development
> will be.
> 
> - So we need to review all packages for sorting out packages that will
> build *.so files. That's how I understand the Gentoo rule. Am I right?
> We can use a script crawling through /* for *.so | pacman -Qo to get the
> packages we need to patch with CFLAGS="$CFLAGS -fPIC" ??? Who can do
> this first? Then check the result against Gentoo and Fedora.
> 
> - Then a recompile of the whole distro will be needed. makeworld will be
> my friend :)
> 
> I hope this will solve our last problems with the iso(mkfs.ext3, lilo, grub)

I read that as meaning -fPIC should be applied to shared object _only_. 
This would involve patching the configure scripts and not just simply 
adding -fPIC to the entire package. Someone else want to weigh in with 
an interpretation on this? I took a look at some ebuilds from Gentoo and 
they seem to use patches for apps that require this which we could 
easily use.

> What I expect from the official archlinux developers side:
> 
> - Jason, I've come to the conclusion that a common cvs and common
> pkgbuilds are not good for getting the ports accepted. It would take us
> a long time until i686 developers will accept bloated pkgbuilds and
> preparing the "arch" tag would take its time. I still don't know why we
> should need the "arch" tag. I think it would be only to declare if the
> pkgbuild builds on a certain architecture. But as long as the packages
> are build by a packager and not automatically we don't really need it.
> 
> - I disagree to your opinion that i686 packagers will ever be able to
> build packages for the ports using pacbuild. Every package needs a check
> and real installation on the destination architecture before you can
> upload it to the repos. So you always will need to have a few packagers
> more for each port to check packages and play with bugfixes.
> 
> - So I would prefer a separate svn/cvs for each port. Every port should
> be free to decide what packages to include into the port. This may not
> be as elegant as common cvs+pkgbuild but it's much easier to handle.
> 
> - No changes would be need to pacman/makepkg. Less work and less
> learning for all - more KISS for everyone. And it will not take more
> space on the servers or something like that.

Seperating the CVS/SVN repo is a touchy subject, to keep things globally 
in sync it would be so much easier to keep them together. To be honest 
I've done all my building from the Arch32 ABS tree because that way I 
know I'm building up to date packages. Splitting the repo means we're 
completely seperating the package tree however it allows us the freedom 
to apply fixes at our own pace. It also means that for packages that 
don't require any changes, we still have to update version numbers and 
monitor the Arch32 bug tracker to keep up with releases.

Using a unified CVS repo with arch tags seems to make sense to me at the 
moment but I haven't been following this ML until yesterday so feel free 
to ignore the newbie :-)

- Cameron