[aur-general] Advice needed maintaining boost-compute
Hello! I recently started maintaining small AUR packages (basically just updating version numbers on git packages and so on), and I came into a little situation when updating the boost-compute [1] package. The package is basically a header-only library, typically providing files under /usr/include/boost/compute. The package can be installed without trouble using the usual makepkg + pacman -U combo. However when I tried to install the package using yaourt, I realised a little something: the package depends on boost [2], which now seems to provide the boost-compute library as part of its own code. This means that when I install boost-compute using yaourt, it first pulls boost from the extra repositories, which brings the include/compute/ files, and creates a conflict when boost-compute comes afterwards (yaourt seems to detect the conflict and therefore stops). I'm guessing the reason why the makepkg approach works is because it doesn't run these checks, and the boost files are simply overwritten (the PKGBUILD runs a simple cp). So here's what I'm hesitating about: - Should I ignore yaourt, and keep maintaining boost-compute separately? I guess this could be of some use if at some point the library gets updated and Boost doesn't bring the changes in immediately (those in a hurry could simply overwrite the Boost files with pacman -U). - Should the boost-compute package simply be deleted, since it requires boost anyway, and Boost is probably going to update the compute code fast enough? Thanks in advance for your advice! [1]: https://aur.archlinux.org/packages/boost-compute/ [2]: https://www.archlinux.org/packages/extra/x86_64/boost/ -- Julien JPK (0xC3075A58) julienjpk@email.com
On Fri, 11 Nov 2016 16:37:23 +0000
Julien JPK
I'm guessing the reason why the makepkg approach works is because it doesn't run these checks, and the boost files are simply overwritten (the PKGBUILD runs a simple cp). So here's what I'm hesitating about:
The checks are done by pacman. I'm guessing you haven't tried with makepkg + pacman -U since the boost update.
On 11/11/16 16:45, Doug Newgard wrote:
The checks are done by pacman. I'm guessing you haven't tried with makepkg + pacman -U since the boost update.
Alright so now I'm really lost. I'm certain I built and installed the package successfully before sending the new PKGBUILD, and now that I try again, I do get the errors. I must have forgotten something when I tried the first time. So basically since that's not an option anymore, I'm guessing the package is no longer of any use separately. On 11/11/16 16:51, Eli Schwartz via aur-general wrote:
Do you mean, pushing a new pkgver after releases? This is only a user convenience, no need to hunt down packages to do this (and definitely please don't nudge maintainers to do so).
To be honest I was just picking packages I was interested in, with the idea of maintaining them on a longer term should it become necessary. I understand that the packages I've chosen so far are not tremendously active, I just thought these simple update tasks would be a good place to start after the wiki. I guess that was yet another mistake... On 11/11/16 16:51, Eli Schwartz via aur-general wrote:
Thank you for validating the opinions of those who believe all yaourt users are complete idiots, by the way... I happen to be a yaourt user who likes to think yaourt users can be intelligent people too, but you are hurting my efforts.
I'm not quite sure where you're going with this. While I'm not actually a yaourt user, I thought it would be a good way to "confirm" that the update had gone through and the updated package was indeed available. Now I'm guessing my 3rd mistake is hidden somewhere in there. Thank you for your answers, and sorry for the disturbance. Turns out I just hadn't been thorough enough in my work. -- Julien JPK (0xC3075A58) julienjpk@email.com
Em novembro 11, 2016 15:14 Julien JPK escreveu:
On 11/11/16 16:45, Doug Newgard wrote:
Alright so now I'm really lost. I'm certain I built and installed the package successfully before sending the new PKGBUILD, and now that I try again, I do get the errors. I must have forgotten something when I tried the first time. So basically since that's not an option anymore, I'm guessing the package is no longer of any use separately.
Packages re-use the building directory. This is were building in a clean chroot comes in handy. At minimum, use makepkg's -C option.
To be honest I was just picking packages I was interested in, with the idea of maintaining them on a longer term should it become necessary. I understand that the packages I've chosen so far are not tremendously active, I just thought these simple update tasks would be a good place to start after the wiki. I guess that was yet another mistake...
Nothing wrong on maintaining the occasional package.
I'm not quite sure where you're going with this. While I'm not actually a yaourt user, I thought it would be a good way to "confirm" that the update had gone through and the updated package was indeed available. Now I'm guessing my 3rd mistake is hidden somewhere in there.
Thank you for your answers, and sorry for the disturbance. Turns out I just hadn't been thorough enough in my work.
Using a helper to confirm if a PKGBUILD is "ok" is so bad of a practice that I don't even know where to begin. Use the tools for the job, makepkg and, devtools. Let the helpers to deal with it. It's their job to make sure your package installs (provided you follow best practices). Cheers, Giancarlo Razzolini
On 11/11/16 17:47, Giancarlo Razzolini via aur-general wrote:
Using a helper to confirm if a PKGBUILD is "ok" is so bad of a practice that I don't even know where to begin. Use the tools for the job, makepkg and, devtools. Let the helpers to deal with it. It's their job to make sure your package installs (provided you follow best practices).
I'm pretty sure I'd get in trouble if I flooded the git commit log trying to fix my mistakes through yaourt. That's like trying to fix a bug in a production environment... Fact is, I should have been more careful when building with makepkg ; yaourt was just intended as a final "polish" to make sure the "quick and easy" install worked. I should have noticed the error when building:
Packages re-use the building directory. This is were building in a clean chroot comes in handy. At minimum, use makepkg's -C option.
Yup, I'll make sure I confirm the build's validity in a clean(er) environment in the future. I did encounter the conflict earlier but I disregarded it because I thought it was simply due to the mess of a previous install. Using yaourt simply pointed it out again (probably because it is more systematic than I am), but at this point in the updating process, I agree that no errors should have occurred: On 11/11/16 18:02, Eli Schwartz via aur-general wrote:
yaourt can only tell you if you successfully pushed the update to the AUR website.
Exactly, that's what I intended to use it for. Instead, it pointed out a mistake I had missed earlier.
I strongly encourage you to learn how the package management and dependency/conflict resolution system works, it is extremely valuable information for any AUR user (whether they maintain packages or just download them).
I have a few things to review before I start working on actually significant package updates. I'll make sure I have a cleaner "AUR maintaining" environment to avoid missing such obvious errors in the future. I'll also make myself more acquainted with the whole process, since a better understanding of it would have signalled the error to me in time. Regarding boost-compute, I suppose I'll just file a deletion request for the package. Anyone using it has had to download boost anyway, and if they kept their system up-to-date, they should already have the compute code from the boost package in extra. Thanks again! -- Julien JPK (0xC3075A58) julienjpk@email.com
On 11/11/2016 01:19 PM, Julien JPK wrote:
I have a few things to review before I start working on actually significant package updates. I'll make sure I have a cleaner "AUR maintaining" environment to avoid missing such obvious errors in the future. I'll also make myself more acquainted with the whole process, since a better understanding of it would have signalled the error to me in time.
Sounds like a plan. :) In case you are also looking for a way to easily maintain the local clones of your AUR repo, here is a free plug for my setup: https://github.com/eli-schwartz/pkgbuilds As Giancarlo Razzolini mentioned, using makechrootpkg from the devtools project is a great way to make sure you are doing things right (including proper dependencies) -- it is what the Arch devs use to build the core/extra/community repositories.
Regarding boost-compute, I suppose I'll just file a deletion request for the package. Anyone using it has had to download boost anyway, and if they kept their system up-to-date, they should already have the compute code from the boost package in extra.
That sounds like the right approach. A little exploring gets me this gem from the docs: "Boost.Compute is not yet an offical Boost library and therefore is not packaged with the standard Boost distribution." I guess that has just changed, note the GitHub repo also redirects from the "kylelutz" account to "boostorg"... which is remarkable timing for your decision to adopt it. ;) Still, learning what this kind of issue means can only be a good thing, I am sure you will recognize such problems in the future. :) -- Eli Schwartz
On 11/11/2016 12:14 PM, Julien JPK wrote:
To be honest I was just picking packages I was interested in, with the idea of maintaining them on a longer term should it become necessary. I understand that the packages I've chosen so far are not tremendously active, I just thought these simple update tasks would be a good place to start after the wiki. I guess that was yet another mistake...
It's no particularly a mistake. Just keep in mind that *-git packages don't *need* to be updated. If the maintainer has time on their hands they are free to push a new version with the latest from-git $pkgver -- and I do that myself. Some people though, flag those packages as out of date, or even file orphan requests when the maintainer ignores them (because it *isn't* out of date). We had a nudnik like that recently, and it was NOT okay! (He got banned by a TU, happily.) ... Adopting an orphaned *-git package and updating the $pkgver is fine (as long as you don't spam people with updates for every commit and stick to updating on every upstream release, but I doubt you intend to do that, so it is all good). Updating non-git packages is very helpful. :)
I'm not quite sure where you're going with this. While I'm not actually a yaourt user, I thought it would be a good way to "confirm" that the update had gone through and the updated package was indeed available. Now I'm guessing my 3rd mistake is hidden somewhere in there.
Thank you for your answers, and sorry for the disturbance. Turns out I just hadn't been thorough enough in my work.
yaourt can only tell you if you successfully pushed the update to the AUR website. So it didn't confirm anything other than that you don't know where the boundaries between AUR helpers, makepkg, and pacman lie. .. It scares me when people think that yaourt is somehow doing something that pacman wouldn't do on its own. yaourt wraps pacman with an interface to the AUR, just like any AUR helper. Other than the default or configured build directory (which sets the working directory of `curl $aur_package_downloadurl` and `makepkg`), using yaourt or any other AUR helper is exactly the same as manually downloading the PKGBUILD, running `makepkg` and `pacman -U`. AUR helpers are all about automating the tedious job of downloading and checking PKGBUILD dependencies by hand. That. Is. ALL! The suggestion that makepkg "doesn't run these checks, and the boost files are simply overwritten (the PKGBUILD runs a simple cp)" is downright terrifying, and carries the implication that you have absolutely no idea what it is that makepkg or pacman actually does, and certainly have no clue how to responsibly use an AUR helper. I strongly encourage you to learn how the package management and dependency/conflict resolution system works, it is extremely valuable information for any AUR user (whether they maintain packages or just download them). -- Eli Schwartz
On 11/11/2016 11:37 AM, Julien JPK wrote:
Hello!
I recently started maintaining small AUR packages (basically just updating version numbers on git packages and so on), and I came into a little situation when updating the boost-compute [1] package.
Do you mean, pushing a new pkgver after releases? This is only a user convenience, no need to hunt down packages to do this (and definitely please don't nudge maintainers to do so).
The package is basically a header-only library, typically providing files under /usr/include/boost/compute. The package can be installed without trouble using the usual makepkg + pacman -U combo.
No it can't, since the package depends on boost and conflicts with files in boost. It has nothing to do with yaourt, yaourt runs makepkg under the hood to build the package, and runs pacman under the hood to install the package. pacman will not install this package unless you use the "--force" or "--nodeps" flags, which is a sign that something is deeply wrong.
However when I tried to install the package using yaourt, I realised a little something: the package depends on boost [2], which now seems to provide the boost-compute library as part of its own code. This means that when I install boost-compute using yaourt, it first pulls boost from the extra repositories, which brings the include/compute/ files, and creates a conflict when boost-compute comes afterwards (yaourt seems to detect the conflict and therefore stops).
I'm guessing the reason why the makepkg approach works is because it doesn't run these checks, and the boost files are simply overwritten (the PKGBUILD runs a simple cp). So here's what I'm hesitating about:
Thank you for validating the opinions of those who believe all yaourt users are complete idiots, by the way... I happen to be a yaourt user who likes to think yaourt users can be intelligent people too, but you are hurting my efforts. -- Eli Schwartz
participants (4)
-
Doug Newgard
-
Eli Schwartz
-
Giancarlo Razzolini
-
Julien JPK