[arch-dev-public] -ARCH package extension

newer
[arch-dev-public] we want to give...

older
[arch-dev-public] thoughts about...

Paul Mattal

11 May 2007 11 May '07

4:47 p.m.

Since pacman 3, makepkg builds: foo-2.9-1-i686.pkg.tar.gz instead of the old foo-2.9-1.pkg.tar.gz What is our migration path for using that in all the repos? More specifically: * How do we tell pacman to start using the new syntax when looking for packages? Do we need to, or do the repo db files take care of that? * How do we synchronize the update of devtools and aurtools? * How do we control/manage the propagating all that via mirrors, since all the filenames will change and each mirror will essentially want to do a full re-download? * Do we announce some time for a flashover and tell devs not to update packages during that time? Maybe someone's already figure this all out, but it would be nice to know how this is going to be handled so we can decide what to do to plan ahead. - P

Show replies by date

Dan McGee

11 May 11 May

5:07 p.m.

On 5/11/07, Paul Mattal wrote:

...

Since pacman 3, makepkg builds:

foo-2.9-1-i686.pkg.tar.gz

instead of the old

foo-2.9-1.pkg.tar.gz

What is our migration path for using that in all the repos? More specifically:

Thought we got some word out on this, but I'll try to state what we were planning on doing.

...

* How do we tell pacman to start using the new syntax when looking for packages? Do we need to, or do the repo db files take care of that?

Pacman 3.0 is fully compatible with the old or new names. The DBs now contain a %FILENAME% field that tells pacman where the package is located. However, pacman 2.X will fail on anything other than the old standard name. This means that for some period of time (feedback would be nice on this), we need to keep packages with the old naming scheme so pacman 2.X users can still use our sync DBs. At some point we can stop the renaming of packages.

...

* How do we synchronize the update of devtools and aurtools?

I personally use a bash function to rename my built packages stripping the arch name from them. I'll paste it at the bottom. Another thought is to modify the line in makepkg that names the package, but that is a bit hackish.

...

* How do we control/manage the propagating all that via mirrors, since all the filenames will change and each mirror will essentially want to do a full re-download?

Old files are not affected- we don't need to do anything to them.

...

* Do we announce some time for a flashover and tell devs not to update packages during that time?

We shouldn't have to have any holding period, as both names are fine in the eyes of pacman 3.0. However, we will need to decide a time when we will stop renaming the packages to names without the -ARCH extension.

...

Maybe someone's already figure this all out, but it would be nice to know how this is going to be handled so we can decide what to do to plan ahead.

Sorry if the ball got dropped here. By the way, the reasoning behind adding the -ARCH to the packages is simple- it prevents (slows down?) users from installing a package they shouldn't on their architecture. Before, you could not tell without unzipping the package which architecture it was built for- this allows us to be completely sure. In addition, it opens up things before that weren't possible, such as having packages for two architectures in the same directory (I'm not suggesting this, just saying it is now possible). Here is that bash function (it isn't idempotent, only run it once): makeoldname() { mv $1 "${1%-*.pkg.tar.gz}.pkg.tar.gz" } -Dan

Thomas Bächler

5:51 p.m.

Dan McGee schrieb:

...

Here is that bash function (it isn't idempotent, only run it once): makeoldname() { mv $1 "${1%-*.pkg.tar.gz}.pkg.tar.gz" }

I used this function: rmi686() { n=$(echo $1 | sed 's|-i686||') if [ ! -e $n ]; then mv $1 $n else echo "$n alread exists." fi } But it got inconvenient, so I changed extrapkg: --- usr/bin/extrapkg 2006-04-28 04:54:19.000000000 +0200 +++ /usr/bin/extrapkg 2007-05-08 23:08:57.000000000 +0200 @@ -10,7 +10,9 @@ fi source PKGBUILD +pkg3file=${pkgname}-${pkgver}-${pkgrel}-i686.pkg.tar.gz pkgfile=${pkgname}-${pkgver}-${pkgrel}.pkg.tar.gz +[ -f $pkg3file ] && mv $pkg3file $pkgfile if [ ! -f $pkgfile ]; then pkgfile=$PKGDEST/$pkgfile Works better IMO and doesn't add an extra step to package management. Maybe we should add a similar workaround in devtools for now, as all devs and TUs use it.

Aaron Griffin

6:05 p.m.

On 5/11/07, Thomas Bächler wrote:

...

--- usr/bin/extrapkg 2006-04-28 04:54:19.000000000 +0200 +++ /usr/bin/extrapkg 2007-05-08 23:08:57.000000000 +0200 @@ -10,7 +10,9 @@ fi

source PKGBUILD +pkg3file=${pkgname}-${pkgver}-${pkgrel}-i686.pkg.tar.gz pkgfile=${pkgname}-${pkgver}-${pkgrel}.pkg.tar.gz +[ -f $pkg3file ] && mv $pkg3file $pkgfile

if [ ! -f $pkgfile ]; then pkgfile=$PKGDEST/$pkgfile

Works better IMO and doesn't add an extra step to package management. Maybe we should add a similar workaround in devtools for now, as all devs and TUs use it.

I was thinking about that too - it'd make a decent intermediate step. Jason? What do you think, devtools is your baby

Dan McGee

6:30 p.m.

On 5/11/07, Aaron Griffin wrote:

...

On 5/11/07, Thomas Bächler wrote:

...
--- usr/bin/extrapkg 2006-04-28 04:54:19.000000000 +0200 +++ /usr/bin/extrapkg 2007-05-08 23:08:57.000000000 +0200 @@ -10,7 +10,9 @@ fi

source PKGBUILD +pkg3file=${pkgname}-${pkgver}-${pkgrel}-i686.pkg.tar.gz pkgfile=${pkgname}-${pkgver}-${pkgrel}.pkg.tar.gz +[ -f $pkg3file ] && mv $pkg3file $pkgfile

if [ ! -f $pkgfile ]; then pkgfile=$PKGDEST/$pkgfile

Works better IMO and doesn't add an extra step to package management. Maybe we should add a similar workaround in devtools for now, as all devs and TUs use it.

I was thinking about that too - it'd make a decent intermediate step.

Jason? What do you think, devtools is your baby

We can rebuild a patched devtools for now in the repos regardless. Have it look for either package name and rename it to the old style name? Any takers? I like the patch above. -Dan

Aaron Griffin

6:37 p.m.

On 5/11/07, Dan McGee wrote:

...

On 5/11/07, Aaron Griffin wrote:

...
On 5/11/07, Thomas Bächler wrote:

...
--- usr/bin/extrapkg 2006-04-28 04:54:19.000000000 +0200 +++ /usr/bin/extrapkg 2007-05-08 23:08:57.000000000 +0200 @@ -10,7 +10,9 @@ fi

source PKGBUILD +pkg3file=${pkgname}-${pkgver}-${pkgrel}-i686.pkg.tar.gz pkgfile=${pkgname}-${pkgver}-${pkgrel}.pkg.tar.gz +[ -f $pkg3file ] && mv $pkg3file $pkgfile

if [ ! -f $pkgfile ]; then pkgfile=$PKGDEST/$pkgfile

Works better IMO and doesn't add an extra step to package management. Maybe we should add a similar workaround in devtools for now, as all devs and TUs use it.

I was thinking about that too - it'd make a decent intermediate step.

Jason? What do you think, devtools is your baby

We can rebuild a patched devtools for now in the repos regardless. Have it look for either package name and rename it to the old style name? Any takers? I like the patch above.

Looks good, though we probably want some form of 'CARCH' in there. Set a global "CARCH='i686'" and sed it out for x86_64 ?

Dan McGee

7:28 p.m.

On 5/11/07, Aaron Griffin wrote:

...

On 5/11/07, Dan McGee wrote:

...
On 5/11/07, Aaron Griffin wrote:

...
On 5/11/07, Thomas Bächler wrote:

...
--- usr/bin/extrapkg 2006-04-28 04:54:19.000000000 +0200 +++ /usr/bin/extrapkg 2007-05-08 23:08:57.000000000 +0200 @@ -10,7 +10,9 @@ fi

source PKGBUILD +pkg3file=${pkgname}-${pkgver}-${pkgrel}-i686.pkg.tar.gz pkgfile=${pkgname}-${pkgver}-${pkgrel}.pkg.tar.gz +[ -f $pkg3file ] && mv $pkg3file $pkgfile

if [ ! -f $pkgfile ]; then pkgfile=$PKGDEST/$pkgfile

Works better IMO and doesn't add an extra step to package management. Maybe we should add a similar workaround in devtools for now, as all devs and TUs use it.

I was thinking about that too - it'd make a decent intermediate step.

Jason? What do you think, devtools is your baby

We can rebuild a patched devtools for now in the repos regardless. Have it look for either package name and rename it to the old style name? Any takers? I like the patch above.

Looks good, though we probably want some form of 'CARCH' in there.

Set a global "CARCH='i686'" and sed it out for x86_64 ?

devtools are updated with a patch now. It should be able to find packages with either name, and will rename them for now to the pacman2-compatible name. -Dan

Jason Chu

12 May 12 May

1 a.m.

On Fri, May 11, 2007 at 03:28:18PM -0400, Dan McGee wrote:

...

On 5/11/07, Aaron Griffin wrote:

...
On 5/11/07, Dan McGee wrote:

...
On 5/11/07, Aaron Griffin wrote:

...
On 5/11/07, Thomas Bächler wrote:

...
--- usr/bin/extrapkg 2006-04-28 04:54:19.000000000 +0200 +++ /usr/bin/extrapkg 2007-05-08 23:08:57.000000000 +0200 @@ -10,7 +10,9 @@ fi

source PKGBUILD +pkg3file=${pkgname}-${pkgver}-${pkgrel}-i686.pkg.tar.gz pkgfile=${pkgname}-${pkgver}-${pkgrel}.pkg.tar.gz +[ -f $pkg3file ] && mv $pkg3file $pkgfile

if [ ! -f $pkgfile ]; then pkgfile=$PKGDEST/$pkgfile

Works better IMO and doesn't add an extra step to package management. Maybe we should add a similar workaround in devtools for now, as all devs and TUs use it.

I was thinking about that too - it'd make a decent intermediate step.

Jason? What do you think, devtools is your baby

We can rebuild a patched devtools for now in the repos regardless. Have it look for either package name and rename it to the old style name? Any takers? I like the patch above.

Looks good, though we probably want some form of 'CARCH' in there.

Set a global "CARCH='i686'" and sed it out for x86_64 ?

devtools are updated with a patch now. It should be able to find packages with either name, and will rename them for now to the pacman2-compatible name.

-Dan

I don't know if I want to release a version of devtools for this. It's a feature that will just have to be taken out when we want to move over to the -ARCH suffix for really. Thoughts? Jason

Aaron Griffin

1:05 a.m.

On 5/11/07, Jason Chu wrote:

...

On Fri, May 11, 2007 at 03:28:18PM -0400, Dan McGee wrote:

...
On 5/11/07, Aaron Griffin wrote:

...
On 5/11/07, Dan McGee wrote:

...
On 5/11/07, Aaron Griffin wrote:

...
On 5/11/07, Thomas Bächler wrote:

...
--- usr/bin/extrapkg 2006-04-28 04:54:19.000000000 +0200 +++ /usr/bin/extrapkg 2007-05-08 23:08:57.000000000 +0200 @@ -10,7 +10,9 @@ fi

source PKGBUILD +pkg3file=${pkgname}-${pkgver}-${pkgrel}-i686.pkg.tar.gz pkgfile=${pkgname}-${pkgver}-${pkgrel}.pkg.tar.gz +[ -f $pkg3file ] && mv $pkg3file $pkgfile

if [ ! -f $pkgfile ]; then pkgfile=$PKGDEST/$pkgfile

Works better IMO and doesn't add an extra step to package management. Maybe we should add a similar workaround in devtools for now, as all devs and TUs use it.

I was thinking about that too - it'd make a decent intermediate step.

Jason? What do you think, devtools is your baby

We can rebuild a patched devtools for now in the repos regardless. Have it look for either package name and rename it to the old style name? Any takers? I like the patch above.

Looks good, though we probably want some form of 'CARCH' in there.

Set a global "CARCH='i686'" and sed it out for x86_64 ?

devtools are updated with a patch now. It should be able to find packages with either name, and will rename them for now to the pacman2-compatible name.

-Dan

I don't know if I want to release a version of devtools for this. It's a feature that will just have to be taken out when we want to move over to the -ARCH suffix for really.

Thoughts?

Well, it's not really a huge deal to push a new version is it? What are the downsides? In addition, the repos may have to remain in this state for a little bit, so we can get to the point where everyone has updated, and we have a new ISO - that could take a month of more. And a month of manually moving packages is gonna get tedious. I just figure, it's not a huge deal to push a new version, and it can't really cause any harm.

James

1:12 a.m.

On 5/12/07, Aaron Griffin wrote:

...

Well, it's not really a huge deal to push a new version is it? What are the downsides?

In addition, the repos may have to remain in this state for a little bit, so we can get to the point where everyone has updated, and we have a new ISO - that could take a month of more. And a month of manually moving packages is gonna get tedious.

I just figure, it's not a huge deal to push a new version, and it can't really cause any harm.

How about we just do it on the server scripts? Should be a simple change, just use one of the many renaming functions in /arch/db-inc, just before "# move the package files into the ftp directory"? That should cover the repos, no idea about community, where are it's scripts located? James -- iphitus // Arch Developer // iphitus.loudas.com

Thomas Bächler

1:18 a.m.

Aaron Griffin schrieb:

...

...
I don't know if I want to release a version of devtools for this. It's a feature that will just have to be taken out when we want to move over to the -ARCH suffix for really.

Thoughts?

Well, it's not really a huge deal to push a new version is it? What are the downsides?

In addition, the repos may have to remain in this state for a little bit, so we can get to the point where everyone has updated, and we have a new ISO - that could take a month of more. And a month of manually moving packages is gonna get tedious.

Actually Dan already fixed it - and broke it: <snip> source PKGBUILD pkgfile=${pkgname}-${pkgver}-${pkgrel}.pkg.tar.gz pkg3file=${pkgname}-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.gz if [ ! -f $pkgfile -o ! -f $pkg3file ]; then pkgfile=$PKGDEST/$pkgfile pkg3file=$PKGDEST/$pkg3file fi </snip> The if-condition should be with a -a, not with a -o: Normally we have either $pkgfile or $pkg3file existing, extrapkg should only look in $PKGDEST if neither exists, but it looks in $PKGDEST if one of them doesn't exist. Thus it won't find any packages if you don't use $PKGDEST and fail.

Dan McGee

6:57 a.m.

On 5/11/07, Thomas Bächler wrote:

...

Aaron Griffin schrieb:

...
...
I don't know if I want to release a version of devtools for this. It's a feature that will just have to be taken out when we want to move over to the -ARCH suffix for really.

Thoughts?

Well, it's not really a huge deal to push a new version is it? What are the downsides?

In addition, the repos may have to remain in this state for a little bit, so we can get to the point where everyone has updated, and we have a new ISO - that could take a month of more. And a month of manually moving packages is gonna get tedious.

Actually Dan already fixed it - and broke it:

<snip> source PKGBUILD pkgfile=${pkgname}-${pkgver}-${pkgrel}.pkg.tar.gz pkg3file=${pkgname}-${pkgver}-${pkgrel}-${CARCH}.pkg.tar.gz

if [ ! -f $pkgfile -o ! -f $pkg3file ]; then pkgfile=$PKGDEST/$pkgfile pkg3file=$PKGDEST/$pkg3file fi </snip>

The if-condition should be with a -a, not with a -o: Normally we have either $pkgfile or $pkg3file existing, extrapkg should only look in $PKGDEST if neither exists, but it looks in $PKGDEST if one of them doesn't exist. Thus it won't find any packages if you don't use $PKGDEST and fail.

Oops. Sorry. I took the initiative and failed. :P Thanks for fixing it; I for one build things in $PKGDEST so didn't really think about the problems. -Dan

Jason Chu

13 May 13 May

7:30 p.m.

On Fri, May 11, 2007 at 08:05:36PM -0500, Aaron Griffin wrote:

...

On 5/11/07, Jason Chu wrote:

...
On Fri, May 11, 2007 at 03:28:18PM -0400, Dan McGee wrote:

...
On 5/11/07, Aaron Griffin wrote:

...
On 5/11/07, Dan McGee wrote:

...
On 5/11/07, Aaron Griffin wrote:

...
On 5/11/07, Thomas Bächler wrote: > --- usr/bin/extrapkg 2006-04-28 04:54:19.000000000 +0200 > +++ /usr/bin/extrapkg 2007-05-08 23:08:57.000000000 +0200 > @@ -10,7 +10,9 @@ > fi > > source PKGBUILD > +pkg3file=${pkgname}-${pkgver}-${pkgrel}-i686.pkg.tar.gz > pkgfile=${pkgname}-${pkgver}-${pkgrel}.pkg.tar.gz > +[ -f $pkg3file ] && mv $pkg3file $pkgfile > > if [ ! -f $pkgfile ]; then > pkgfile=$PKGDEST/$pkgfile > > Works better IMO and doesn't add an extra step to package management. > Maybe we should add a similar workaround in devtools for now, as all > devs and TUs use it.

I was thinking about that too - it'd make a decent intermediate step.

Jason? What do you think, devtools is your baby

We can rebuild a patched devtools for now in the repos regardless. Have it look for either package name and rename it to the old style name? Any takers? I like the patch above.

Looks good, though we probably want some form of 'CARCH' in there.

Set a global "CARCH='i686'" and sed it out for x86_64 ?

devtools are updated with a patch now. It should be able to find packages with either name, and will rename them for now to the pacman2-compatible name.

-Dan

I don't know if I want to release a version of devtools for this. It's a feature that will just have to be taken out when we want to move over to the -ARCH suffix for really.

Thoughts?

Well, it's not really a huge deal to push a new version is it? What are the downsides?

I mean change svn, tag it, and push a release, not just patch it in the PKGBUILD and release a new revision. The latter was fine. Jason

6192

Age (days ago)

6194

Last active (days ago)

List overview

Download

12 comments

6 participants

participants (6)

Aaron Griffin
Dan McGee
James
Jason Chu
Paul Mattal
Thomas Bächler