2009/5/13 Aaron Griffin aaronmgriffin@gmail.com:
On Tue, May 12, 2009 at 4:57 AM, Firmicus Firmicus@gmx.net wrote:
Aaron Griffin:
Regarding the new convert2any script you added - I'd prefer to fix the existing script rather than add a new one - or at least preserve some of the logic (such as sourcing of makepkg.conf)
All right, perhaps Abhishek can do that? ;)
Yeah, I'm gonna try to merge your changes into the existing script. It's not a show-stopper though
I've attached a diff for convert-to-any which does away with all the committing stuff and just makes an i686/x86_64 package into an architecture independent package putting the file in the same directory. I tested the code here and it's working.
I would've attached a git patch but for some weird reason no application in the terminal can access the net! Firefox works fine though.
2009/5/13 Abhishek Dasgupta abhidg@gmail.com:
I've attached a diff for convert-to-any which does away with all the committing stuff and just makes an i686/x86_64 package into an architecture independent package putting the file in the same directory. I tested the code here and it's working.
updated patch using die() and some other corrections like using quotes when accessing variables, etc.
Currently, I'm copying the i686/x86_64 package to $WORKDIR/build and extracting it there. This causes some additional disk i/o which can be done away with if I directly extract from the package. However this does ensure that the original package is unharmed.
Abhishek Dasgupta a écrit :
2009/5/13 Abhishek Dasgupta abhidg@gmail.com:
I've attached a diff for convert-to-any which does away with all the committing stuff and just makes an i686/x86_64 package into an architecture independent package putting the file in the same directory. I tested the code here and it's working.
updated patch using die() and some other corrections like using quotes when accessing variables, etc.
Currently, I'm copying the i686/x86_64 package to $WORKDIR/build and extracting it there. This causes some additional disk i/o which can be done away with if I directly extract from the package. However this does ensure that the original package is unharmed.
IMHO extracting the package is not really necessary. It is simpler and faster to 1. decompress the package (with gunzip, or eventually some other (de)compression tool, depending of ) 2. extract the .PKGINFO from the tar and then delete it with "tar --delete" 3. modify the extracted .PKGINFO with sed to change the arch field 4. re-add .PKGINFO to the tar with "tar --append" and finally 5. gzip the tar
This has the additional advantage of making sure the properties of the files (ownership and mode) are not mangled. I have tested this procedure with a large number of arch-independent packages that I converted from i686 to x86_64, and I have never encountered a problem. In any case, I leave it to our benevolent dictator Aaron to decide which solution is to be preferred ;)
F
PS: change the description header as follows:
diff --git a/convert-to-any b/convert-to-any index 1c48eb3..72dad04 100644 --- a/convert-to-any +++ b/convert-to-any @@ -1,8 +1,8 @@ #!/bin/bash -# Converts an existing package into an -# architecture-independent package and updates -# the repositories accordingly. - +# +# Converts an existing architecture-independent package +# for i686 or x86_64 into a package with "arch = any" +# # -- Abhishek Dasgupta abhidg@gmail.com
[ "$UID" = "" ] && UID=$(uid)
On Wed, May 13, 2009 at 1:44 PM, Firmicus Firmicus@gmx.net wrote:
Abhishek Dasgupta a écrit :
2009/5/13 Abhishek Dasgupta abhidg@gmail.com:
I've attached a diff for convert-to-any which does away with all the committing stuff and just makes an i686/x86_64 package into an architecture independent package putting the file in the same directory. I tested the code here and it's working.
updated patch using die() and some other corrections like using quotes when accessing variables, etc.
Currently, I'm copying the i686/x86_64 package to $WORKDIR/build and extracting it there. This causes some additional disk i/o which can be done away with if I directly extract from the package. However this does ensure that the original package is unharmed.
IMHO extracting the package is not really necessary. It is simpler and faster to
- decompress the package (with gunzip, or eventually some other
(de)compression tool, depending of ) 2. extract the .PKGINFO from the tar and then delete it with "tar --delete" 3. modify the extracted .PKGINFO with sed to change the arch field 4. re-add .PKGINFO to the tar with "tar --append" and finally 5. gzip the tar
This has the additional advantage of making sure the properties of the files (ownership and mode) are not mangled. I have tested this procedure with a large number of arch-independent packages that I converted from i686 to x86_64, and I have never encountered a problem. In any case, I leave it to our benevolent dictator Aaron to decide which solution is to be preferred ;)
One quick thing to note - because pacman reads .PKGINFO files to get metadata, it's nice to have them at the beginning of the tar. tar --append is going to slap them on the end. This could make a significant difference on larger packages
PS: change the description header as follows:
diff --git a/convert-to-any b/convert-to-any index 1c48eb3..72dad04 100644 --- a/convert-to-any +++ b/convert-to-any @@ -1,8 +1,8 @@ #!/bin/bash -# Converts an existing package into an -# architecture-independent package and updates -# the repositories accordingly.
+# +# Converts an existing architecture-independent package +# for i686 or x86_64 into a package with "arch = any" +# # -- Abhishek Dasgupta abhidg@gmail.com
[ "$UID" = "" ] && UID=$(uid)
Merged and pushed both patches
2009/5/14 Aaron Griffin aaronmgriffin@gmail.com:
One quick thing to note - because pacman reads .PKGINFO files to get metadata, it's nice to have them at the beginning of the tar. tar --append is going to slap them on the end. This could make a significant difference on larger packages
The previous commit was actually placing .PKGINFO at the end. The attached patch fixes that and also uses fakeroot otherwise the tarball would get the permissions of the user running convert-to-any.
2009/5/14 Abhishek Dasgupta abhidg@gmail.com:
2009/5/14 Aaron Griffin aaronmgriffin@gmail.com:
One quick thing to note - because pacman reads .PKGINFO files to get metadata, it's nice to have them at the beginning of the tar. tar --append is going to slap them on the end. This could make a significant difference on larger packages
The previous commit was actually placing .PKGINFO at the end. The attached patch fixes that and also uses fakeroot otherwise the tarball would get the permissions of the user running convert-to-any.
forgot to attach last time.
On Wed, May 13, 2009 at 2:18 PM, Abhishek Dasgupta abhidg@gmail.com wrote:
2009/5/14 Abhishek Dasgupta abhidg@gmail.com:
2009/5/14 Aaron Griffin aaronmgriffin@gmail.com:
One quick thing to note - because pacman reads .PKGINFO files to get metadata, it's nice to have them at the beginning of the tar. tar --append is going to slap them on the end. This could make a significant difference on larger packages
The previous commit was actually placing .PKGINFO at the end. The attached patch fixes that and also uses fakeroot otherwise the tarball would get the permissions of the user running convert-to-any.
forgot to attach last time.
Pushed. Danke.
2009/5/14 Aaron Griffin aaronmgriffin@gmail.com:
On Wed, May 13, 2009 at 2:18 PM, Abhishek Dasgupta abhidg@gmail.com wrote:
2009/5/14 Abhishek Dasgupta abhidg@gmail.com:
2009/5/14 Aaron Griffin aaronmgriffin@gmail.com:
One quick thing to note - because pacman reads .PKGINFO files to get metadata, it's nice to have them at the beginning of the tar. tar --append is going to slap them on the end. This could make a significant difference on larger packages
The previous commit was actually placing .PKGINFO at the end. The attached patch fixes that and also uses fakeroot otherwise the tarball would get the permissions of the user running convert-to-any.
forgot to attach last time.
Bump. Probably this can be tried out for the kde-unstable branch to iron out any bugs that are remaining?
On Wed, Jun 24, 2009 at 7:03 AM, Abhishek Dasguptaabhidg@gmail.com wrote:
2009/5/14 Aaron Griffin aaronmgriffin@gmail.com:
On Wed, May 13, 2009 at 2:18 PM, Abhishek Dasgupta abhidg@gmail.com wrote:
2009/5/14 Abhishek Dasgupta abhidg@gmail.com:
2009/5/14 Aaron Griffin aaronmgriffin@gmail.com:
One quick thing to note - because pacman reads .PKGINFO files to get metadata, it's nice to have them at the beginning of the tar. tar --append is going to slap them on the end. This could make a significant difference on larger packages
The previous commit was actually placing .PKGINFO at the end. The attached patch fixes that and also uses fakeroot otherwise the tarball would get the permissions of the user running convert-to-any.
forgot to attach last time.
Bump. Probably this can be tried out for the kde-unstable branch to iron out any bugs that are remaining?
Which part? Is there a patch I forgot to merge, or are you just bumping the dbscripts as a whole?
2009/6/24 Aaron Griffin aaronmgriffin@gmail.com:
Which part? Is there a patch I forgot to merge, or are you just bumping the dbscripts as a whole?
No, I was just saying that the any architecture could be tried out for the kde-unstable branch to find any remaining bugs.
Abhishek Dasgupta wrote:
2009/6/24 Aaron Griffin aaronmgriffin@gmail.com:
Which part? Is there a patch I forgot to merge, or are you just bumping the dbscripts as a whole?
No, I was just saying that the any architecture could be tried out for the kde-unstable branch to find any remaining bugs.
I discussed this with Pierre yesterday. The issues are that kde-unstable does not use the db-scripts as such and there is no real arch="any" packages there.
Allan
On Thu, Jun 25, 2009 at 1:23 AM, Allan McRaeallan@archlinux.org wrote:
Abhishek Dasgupta wrote:
2009/6/24 Aaron Griffin aaronmgriffin@gmail.com:
Which part? Is there a patch I forgot to merge, or are you just bumping the dbscripts as a whole?
No, I was just saying that the any architecture could be tried out for the kde-unstable branch to find any remaining bugs.
I discussed this with Pierre yesterday. The issues are that kde-unstable does not use the db-scripts as such and there is no real arch="any" packages there.
They can... /arch/db-update kde-unstable i686
On Thursday 25 June 2009 17:39:32 Aaron Griffin wrote:
They can... /arch/db-update kde-unstable i686
Yes we can. But it wont work. (hint: split packages)
Pierre Schmitz a écrit :
On Thursday 25 June 2009 17:39:32 Aaron Griffin wrote:
They can... /arch/db-update kde-unstable i686
Yes we can. But it wont work. (hint: split packages)
Then how about creating a dummy "testing-any" repo? We can put, say, a dozen small-sized packages in there for i686 and x86_64, half of which would be for arch=any, and see how it goes. Just my 2¢. I have already a bunch of packages with arch=any here that I could happily commit and upload if you wish.
F
aur-general@lists.archlinux.org