[aur-general] Questions from a new TU
Hi, Just let me know if there is a more appropriate place for this and sorry for all eventual noobishness. 1) Why are the "x86_64" and "i686" tags stripped out of package names? Wouldn't it make more sense to use these tags to determine the port when uploading binary packages to community? This would also be useful for uploading "any" packages (which I suppose need to be uploaded twice). 2) How can I upload both x86_64 and i686 packages from the same machine? When trying to upload an i686 package with communitypkg, it complains that it couldn't find the x86_64 package. I did change the port of tupkg but I didn't try it without communitypkg. 3) Is there any way to avoid re-uploading a package when changing the PKGBUILD if the changes have no effect on the built package (e.g. appending packages to the depends array)? Thanks, Xyne
Xyne wrote:
Hi,
Just let me know if there is a more appropriate place for this and sorry for all eventual noobishness.
1) Why are the "x86_64" and "i686" tags stripped out of package names?
Wouldn't it make more sense to use these tags to determine the port when uploading binary packages to community? This would also be useful for uploading "any" packages (which I suppose need to be uploaded twice).
The community upload scripts are old... This will get fixed when community switches to the official db-scripts that core and extra use.
2) How can I upload both x86_64 and i686 packages from the same machine? When trying to upload an i686 package with communitypkg, it complains that it couldn't find the x86_64 package. I did change the port of tupkg but I didn't try it without communitypkg.
I think you need to alter the CARCH in makepkg.conf? There is a script which does some of this but I have never used it...
3) Is there any way to avoid re-uploading a package when changing the PKGBUILD if the changes have no effect on the built package (e.g. appending packages to the depends array)?
Adding more depends does alter the package... But you can always alter the package in cvs and just do "cvs commit" for things that _really_ do not alter the package. Allan
3) Is there any way to avoid re-uploading a package when changing the PKGBUILD if the changes have no effect on the built package (e.g. appending packages to the depends array)?
Adding more depends does alter the package... But you can always alter the package in cvs and just do "cvs commit" for things that _really_ do not alter the package.
Allan
Thanks for the reply. Will a cvs commit without a binary upload (e.g. when adding a package to the depends array) result in a new binary package in the repo with the correct information? Formulated another way, does the upload server create a new .PKGINFO file and replace the old one while keeping the installable package files?
Xyne wrote:
3) Is there any way to avoid re-uploading a package when changing the PKGBUILD if the changes have no effect on the built package (e.g. appending packages to the depends array)?
Adding more depends does alter the package... But you can always alter the package in cvs and just do "cvs commit" for things that _really_ do not alter the package.
Allan
Thanks for the reply.
Will a cvs commit without a binary upload (e.g. when adding a package to the depends array) result in a new binary package in the repo with the correct information? Formulated another way, does the upload server create a new .PKGINFO file and replace the old one while keeping the installable package files?
The .PKGINFO file is created by makepkg and compressed inside the package. When you upload a package to the server, this file is extracted and an entry is made for the pacman database using this information. So any change that alters the .PKGINFO file or any installed files requires a new binary upload. Have a look at a PKGINFO file and note there are very few things that you can change without uploading a new package. Allan
Allan McRae <allan@archlinux.org> wrote:
The .PKGINFO file is created by makepkg and compressed inside the package. When you upload a package to the server, this file is extracted and an entry is made for the pacman database using this information. So any change that alters the .PKGINFO file or any installed files requires a new binary upload. Have a look at a PKGINFO file and note there are very few things that you can change without uploading a new package.
Allan
I know where the .PKGINFO is stored... I was just hoping that the server would be "smart" enough to handle changes that don't really require a package rebuild, e.g. extract .PKGINFO, update it, re-insert it. Uploading 600 MB * 2 in this case to change a package description just seems silly. Who's mostly in charge of handling such things? Maybe I can help out a bit with some scripts or whatever (resumable uploads would also be good, for instance). Xyne
On Sun, Apr 12, 2009 at 11:23:07PM +0200, Xyne wrote:
Allan McRae <allan@archlinux.org> wrote:
The .PKGINFO file is created by makepkg and compressed inside the package. When you upload a package to the server, this file is extracted and an entry is made for the pacman database using this information. So any change that alters the .PKGINFO file or any installed files requires a new binary upload. Have a look at a PKGINFO file and note there are very few things that you can change without uploading a new package.
I know where the .PKGINFO is stored... I was just hoping that the server would be "smart" enough to handle changes that don't really require a package rebuild, e.g. extract .PKGINFO, update it, re-insert it. Uploading 600 MB * 2 in this case to change a package description just seems silly.
Who's mostly in charge of handling such things? Maybe I can help out a bit with some scripts or whatever (resumable uploads would also be good, for instance).
You could start by looking at devtools. The community repo will be using that system in the near future.
2009/4/12 Xyne <xyne@archlinux.ca>: [ snip ]
Wouldn't it make more sense to use these tags to determine the port when uploading binary packages to community? This would also be useful for uploading "any" packages (which I suppose need to be uploaded twice).
Just to clarify, currently [community] does not support the "any" architecture, so you'll have to use arch=(i686 x86_64)
2) How can I upload both x86_64 and i686 packages from the same machine? When trying to upload an i686 package with communitypkg, it complains that it couldn't find the x86_64 package. I did change the port of tupkg but I didn't try it without communitypkg.
I have a 64-bit machine on which I have a 32-bit chroot where I build the i686 versions, see for example: http://wiki.archlinux.org/index.php/Arch64_FAQ#Can_I_build_32-bit_packages_f... http://wiki.archlinux.org/index.php/Arch64_Install_bundled_32bit_system In the i686 environment which I chroot to using linux32, CARCH etc is set to i686, so communitypkg does not complain. -- Abhishek
participants (4)
-
Abhishek Dasgupta
-
Allan McRae
-
Loui Chang
-
Xyne