[arch-ports] developing the (arch64) port

older
[arch-ports] [Arch64] Slow 32 bit...

Andreas Radke

30 Mar 2006 30 Mar '06

8:36 p.m.

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) 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. So setup a separate svn for arch64 and create new subrepos for x86_64 and give a few of us access - we could start tomorrow! I know some arch64 devs dying to do real productiv stuff. Otherwise as I told you more packagers will leave the port. AndyRTR

Show replies by date

Jason Chu

30 Mar 30 Mar

9:26 p.m.

...

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.

How many developers have complained about "bloated" pkgbuilds so far?

...

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

Every package does need to be checked, but every package does not need to be submitted by an x86_64 person. You will always need packagers for a specific port, but I think the i686 people can help out as well.

...

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

Easier to handle in the short run, sure.

...

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

So setup a separate svn for arch64 and create new subrepos for x86_64 and give a few of us access - we could start tomorrow! I know some arch64 devs dying to do real productiv stuff.

Otherwise as I told you more packagers will leave the port.

AndyRTR

Other developer's thoughts? Jason

ganja.guru

31 Mar 31 Mar

10:36 a.m.

...

...
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 personally don't see a big problem with the so called "bloated" PKGBUILD's. Most PKGBUILDs will be clean cause they compile on arch64 without any changes anyway, and a few PKGBUILDS with a few extra lines here and there shouldn't bother anyone, I think.

...

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

I think having a separate svn/cvs for the ports is too tedious as we have to keep going back and forth when checking out PKGBUILD's for those difficult packages. Integrating everything into a single cvs should save a lot of time. Varun "ganja_guru" Acharya

...

_______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports

Andreas Radke

2:26 p.m.

I'm not stricly against a common cvs tree although it restricts us to be "only" a port without any freedom. It's ok. But then I ask all the involved devs to hurry up setting up all that is needed so we can start as quickly as possible. AndyRTR

Andreas Radke

4 Apr 4 Apr

8:21 p.m.

After some discussions between the x86_64 devs we agree that a common pkgbuild tree is a good solution. It will bind us to follow arch32 as much as possible but that's what a port only is. And that's ok. It would be to dangerous to have a separate tree so it would be a fork from the beginning on. That's not what we want to become. In our view we cannot see anything what holds us from joining your party. In my view we don't really need certain cvs trunks. I guess the i686 devs don't have the intention to move to svn so we will have to work with the same cvs they already use. For checkout we can use csup and for committing cvs. I suggest to keep using first pkgrel number for the i686 packages as you do now. So i686 would build every new pkg with a pkgrel nr. -1. When you fix something you go with -2. Nothing new. Even if nothing will make now use of it I suggest to add an "arch" tag to every pkg for each architecture. Just like Gentoo and Frugal do. So every i686 release will get // arch='i686' // tag. Every package the x86_64 devs will have to port. If it is ok everything stays like it is and we add // arch='i686' 'x86_64' // tag. If a 64bit bugfix is needed we will do a pkg foo-1.1 so only the x86_64 binary will be built. i686 fixes we could leave out if we are not affected but in almost every case we follow and do our own foo-2 pkg. Once we have a pkg marked with our arch x86_64 tag we can think about to try to automatically build next release. But before moving to current each time a 64bit dev will have to mark it for really working well. Is that a way we can go? So I don't see why we should wait any longer. Things like crossbuilding with pacbuild and AUR we can add later. AndyRTR

Jason Chu

10:52 p.m.

On Tue, 04 Apr 2006 22:21:40 +0200 Andreas Radke wrote:

...

After some discussions between the x86_64 devs we agree that a common pkgbuild tree is a good solution. It will bind us to follow arch32 as much as possible but that's what a port only is. And that's ok.

It would be to dangerous to have a separate tree so it would be a fork from the beginning on. That's not what we want to become.

In our view we cannot see anything what holds us from joining your party.

In my view we don't really need certain cvs trunks. I guess the i686 devs don't have the intention to move to svn so we will have to work with the same cvs they already use. For checkout we can use csup and for committing cvs. I suggest to keep using first pkgrel number for the i686 packages as you do now. So i686 would build every new pkg with a pkgrel nr. -1. When you fix something you go with -2. Nothing new.

Even if nothing will make now use of it I suggest to add an "arch" tag to every pkg for each architecture. Just like Gentoo and Frugal do. So every i686 release will get // arch='i686' // tag.

Every package the x86_64 devs will have to port. If it is ok everything stays like it is and we add // arch='i686' 'x86_64' // tag. If a 64bit bugfix is needed we will do a pkg foo-1.1 so only the x86_64 binary will be built. i686 fixes we could leave out if we are not affected but in almost every case we follow and do our own foo-2 pkg.

Once we have a pkg marked with our arch x86_64 tag we can think about to try to automatically build next release. But before moving to current each time a 64bit dev will have to mark it for really working well.

Is that a way we can go?

So I don't see why we should wait any longer.

Things like crossbuilding with pacbuild and AUR we can add later.

AndyRTR

Alright, because you're such a nice guy, here's what I'm prepared to do for you. We'll set you guys up with pserver access to our cvs server (just like the TUs have). Then we'll set up a set of repo update daemons (just like the TUs have). Then you guys can make your PKGBUILD updates, tag your builds (right now we use CURRENT, you guys can use CURRENT-x86_64), and upload the built packages. A script will process the PKGBUILD updates and recreate the repos when it needs to. That's about it. Now, here's the catch. It's gonna take me/us a while to set it up. Work is crazy busy for me and there are only a few people who have experience using the TU daemons and they will need to be modified to work for your purposes. I'm going to set the clock at 2 weeks from today. By the 18th of April. we will have something for you guys to start contributing through. Jason

ganja.guru

5 Apr 5 Apr

1:27 a.m.

Jason Chu wrote:

...

On Tue, 04 Apr 2006 22:21:40 +0200 Andreas Radke wrote:

...
After some discussions between the x86_64 devs we agree that a common pkgbuild tree is a good solution. It will bind us to follow arch32 as much as possible but that's what a port only is. And that's ok.

It would be to dangerous to have a separate tree so it would be a fork from the beginning on. That's not what we want to become.

In our view we cannot see anything what holds us from joining your party.

In my view we don't really need certain cvs trunks. I guess the i686 devs don't have the intention to move to svn so we will have to work with the same cvs they already use. For checkout we can use csup and for committing cvs. I suggest to keep using first pkgrel number for the i686 packages as you do now. So i686 would build every new pkg with a pkgrel nr. -1. When you fix something you go with -2. Nothing new.

Even if nothing will make now use of it I suggest to add an "arch" tag to every pkg for each architecture. Just like Gentoo and Frugal do. So every i686 release will get // arch='i686' // tag.

Every package the x86_64 devs will have to port. If it is ok everything stays like it is and we add // arch='i686' 'x86_64' // tag. If a 64bit bugfix is needed we will do a pkg foo-1.1 so only the x86_64 binary will be built. i686 fixes we could leave out if we are not affected but in almost every case we follow and do our own foo-2 pkg.

Once we have a pkg marked with our arch x86_64 tag we can think about to try to automatically build next release. But before moving to current each time a 64bit dev will have to mark it for really working well.

Is that a way we can go?

So I don't see why we should wait any longer.

Things like crossbuilding with pacbuild and AUR we can add later.

AndyRTR

Alright, because you're such a nice guy, here's what I'm prepared to do for you.

We'll set you guys up with pserver access to our cvs server (just like the TUs have).

Then we'll set up a set of repo update daemons (just like the TUs have).

Then you guys can make your PKGBUILD updates, tag your builds (right now we use CURRENT, you guys can use CURRENT-x86_64), and upload the built packages.

A script will process the PKGBUILD updates and recreate the repos when it needs to.

That's about it.

Now, here's the catch. It's gonna take me/us a while to set it up. Work is crazy busy for me and there are only a few people who have experience using the TU daemons and they will need to be modified to work for your purposes.

I'm going to set the clock at 2 weeks from today. By the 18th of April. we will have something for you guys to start contributing through.

Jason

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

_______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports

Thanks Jason...can't wait ! :-) ganja_guru

Cam Daniel

31 Mar 31 Mar

6:16 p.m.

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

6596

Age (days ago)

6602

Last active (days ago)

List overview

Download

7 comments

4 participants

participants (4)

Andreas Radke
Cam Daniel
ganja.guru
Jason Chu