[aur-general] advice wanted on "surf" package
I'm the maintainer of the "surf" package in AUR, and I've discovered an annoyance in the way I've created this package. I'd like some advice on how to resolve it. This package is a web browser from suckless.org, the makers of dwm. It has very much the same coding and build style, involving a config.h file which the user is intended to customize. Most of surf's behavior is decided at compile-time by this file. I've modeled my package after the "dwm" package in community, copying the default config.h into the root of the package tarball and listing it as a local source file. build() then copies it into the unpacked source directory before compiling. This is great for users of dwm who rebuild it from ABS, as it avoids the need to modify build() in order to customize the package - the user just needs to supply their own config.h and change the md5sum for it. This doesn't work so well for my surf package, though, since that's in the AUR. Many (most?) users of AUR packages are auto-updating with helper-tools like yaourt, pbget, and similar utilities, and it's difficult to automatically pull updates to package materials when you've changed one of the files. customizepkg won't help you much either, since that can only modify the PKGBUILD, and not the config.h. It's also annoying to me as the maintainer of the package. Anyone who maintains a package that's meant to have the build customized, rather than compiled as-is, will end up actually maintaining two copies - one "stock" version to submit to AUR, and one customized version for personal use. Obviously, none of these issues are show-stoppers. But they are annoying, and I don't packages I maintain to annoy my end-users. What can I do to make this package more comfortable for the average AUR user? Is software that expects compile-time customization just fundamentally not very compatible with the auto-update concept?
On Sun, Sep 27, 2009 at 8:14 PM, Ray Kohler <ataraxia937@gmail.com> wrote:
I'm the maintainer of the "surf" package in AUR, and I've discovered an annoyance in the way I've created this package. I'd like some advice on how to resolve it.
This package is a web browser from suckless.org, the makers of dwm. It has very much the same coding and build style, involving a config.h file which the user is intended to customize. Most of surf's behavior is decided at compile-time by this file. I've modeled my package after the "dwm" package in community, copying the default config.h into the root of the package tarball and listing it as a local source file. build() then copies it into the unpacked source directory before compiling.
This is great for users of dwm who rebuild it from ABS, as it avoids the need to modify build() in order to customize the package - the user just needs to supply their own config.h and change the md5sum for it.
This doesn't work so well for my surf package, though, since that's in the AUR. Many (most?) users of AUR packages are auto-updating with helper-tools like yaourt, pbget, and similar utilities, and it's difficult to automatically pull updates to package materials when you've changed one of the files. customizepkg won't help you much either, since that can only modify the PKGBUILD, and not the config.h.
It's also annoying to me as the maintainer of the package. Anyone who maintains a package that's meant to have the build customized, rather than compiled as-is, will end up actually maintaining two copies - one "stock" version to submit to AUR, and one customized version for personal use.
Obviously, none of these issues are show-stoppers. But they are annoying, and I don't packages I maintain to annoy my end-users. What can I do to make this package more comfortable for the average AUR user? Is software that expects compile-time customization just fundamentally not very compatible with the auto-update concept?
dwm was one of the very few softwares I never used a PKGBUILD for and don't recommend using one. And the problem you just described is one of the reasons.
On Sun, Sep 27, 2009 at 2:47 PM, Xavier <shiningxc@gmail.com> wrote:
dwm was one of the very few softwares I never used a PKGBUILD for and don't recommend using one. And the problem you just described is one of the reasons.
It's a little off-topic, but what did you actually do with dwm, then? Use the upstream build system, or script your own? Install into /usr/local, /usr, or somewhere else? hg tip or stable version from tarballs? Basically, I'm asking whether, in the case where you decide not to use a PKGBUILD, do you then follow upstream's installation recommendations, or roll your own?
On Sun, Sep 27, 2009 at 9:00 PM, Ray Kohler <ataraxia937@gmail.com> wrote:
On Sun, Sep 27, 2009 at 2:47 PM, Xavier <shiningxc@gmail.com> wrote:
dwm was one of the very few softwares I never used a PKGBUILD for and don't recommend using one. And the problem you just described is one of the reasons.
It's a little off-topic, but what did you actually do with dwm, then? Use the upstream build system, or script your own? Install into /usr/local, /usr, or somewhere else? hg tip or stable version from tarballs? Basically, I'm asking whether, in the case where you decide not to use a PKGBUILD, do you then follow upstream's installation recommendations, or roll your own?
- upstream build system - hg tip - /usr/local Then I would regularly compare my custom config with the default one, to track the changes. And I think that was following upstream recommendations.
On Sun, Sep 27, 2009 at 2:47 PM, Xavier <shiningxc@gmail.com> wrote:
On Sun, Sep 27, 2009 at 8:14 PM, Ray Kohler <ataraxia937@gmail.com> wrote:
I'm the maintainer of the "surf" package in AUR, and I've discovered an annoyance in the way I've created this package. I'd like some advice on how to resolve it.
This package is a web browser from suckless.org, the makers of dwm. It has very much the same coding and build style, involving a config.h file which the user is intended to customize. Most of surf's behavior is decided at compile-time by this file. I've modeled my package after the "dwm" package in community, copying the default config.h into the root of the package tarball and listing it as a local source file. build() then copies it into the unpacked source directory before compiling.
This is great for users of dwm who rebuild it from ABS, as it avoids the need to modify build() in order to customize the package - the user just needs to supply their own config.h and change the md5sum for it.
This doesn't work so well for my surf package, though, since that's in the AUR. Many (most?) users of AUR packages are auto-updating with helper-tools like yaourt, pbget, and similar utilities, and it's difficult to automatically pull updates to package materials when you've changed one of the files. customizepkg won't help you much either, since that can only modify the PKGBUILD, and not the config.h.
It's also annoying to me as the maintainer of the package. Anyone who maintains a package that's meant to have the build customized, rather than compiled as-is, will end up actually maintaining two copies - one "stock" version to submit to AUR, and one customized version for personal use.
Obviously, none of these issues are show-stoppers. But they are annoying, and I don't packages I maintain to annoy my end-users. What can I do to make this package more comfortable for the average AUR user? Is software that expects compile-time customization just fundamentally not very compatible with the auto-update concept?
dwm was one of the very few softwares I never used a PKGBUILD for and don't recommend using one. And the problem you just described is one of the reasons.
Back on topic, I think I'll wait and see if anybody else has any surprising suggestions that disagree with this one, and if none are forthcoming, I'll disown the surf package. Having a pacman developer tell me not to use pacman for a given purpose is rather convincing, in which case, I should let someone who _isn't_ convinced take on the package and worry about the problem, instead of me. ;)
Le Sun, 27 Sep 2009 17:21:23 -0400, Ray Kohler <ataraxia937@gmail.com> a écrit :
Back on topic, I think I'll wait and see if anybody else has any surprising suggestions that disagree with this one, and if none are forthcoming, I'll disown the surf package. Having a pacman developer tell me not to use pacman for a given purpose is rather convincing, in which case, I should let someone who _isn't_ convinced take on the package and worry about the problem, instead of me. ;)
Well, I am not since I use surf with the stock configuration :) Even if I weren't, I don't use Yaourt or any automatic upgrade tool (but I do have a script that checks and warns me if my packages are outdated) so the way it works now is OK for me. I always install everything with Pacman when I can because it can track the files in my system tree for me. I create custom PKGBUILDs if I need to, even if they have to be ugly. Anyway, I think surf should stay in AUR and be maintained so I'm ready to take ownership of the package if you choose to disown it. -- catwell
On Sun, Sep 27, 2009 at 5:44 PM, Pierre Chapuis <catwell@archlinux.us> wrote:
Le Sun, 27 Sep 2009 17:21:23 -0400, Ray Kohler <ataraxia937@gmail.com> a écrit :
Back on topic, I think I'll wait and see if anybody else has any surprising suggestions that disagree with this one, and if none are forthcoming, I'll disown the surf package. Having a pacman developer tell me not to use pacman for a given purpose is rather convincing, in which case, I should let someone who _isn't_ convinced take on the package and worry about the problem, instead of me. ;)
Well, I am not since I use surf with the stock configuration :)
This may become less attractive in the future as surf becomes less simple, and gains a lot of configuration options. It's my impression, based on what I see on the suckless mailing list, that this is likely to happen.
Even if I weren't, I don't use Yaourt or any automatic upgrade tool (but I do have a script that checks and warns me if my packages are outdated) so the way it works now is OK for me.
I always install everything with Pacman when I can because it can track the files in my system tree for me. I create custom PKGBUILDs if I need to, even if they have to be ugly.
Anyway, I think surf should stay in AUR and be maintained so I'm ready to take ownership of the package if you choose to disown it.
Disowned. It's all yours. Given that you actually use it, and I don't, that would be enough all by itself.
Le Sun, 27 Sep 2009 18:08:45 -0400, Ray Kohler <ataraxia937@gmail.com> a écrit :
Disowned. It's all yours. Given that you actually use it, and I don't, that would be enough all by itself.
Adopted, although I hadn't noticed there was another package than the one I used, which was surf-hg. But I was thinking of switching to the stable branch anyway. -- catwell
On Sun, Sep 27, 2009 at 11:44 PM, Pierre Chapuis <catwell@archlinux.us> wrote:
I always install everything with Pacman when I can because it can track the files in my system tree for me.
Don't get me wrong though :) Just earlier today, I was arguing with a user who installed imagemagick manually and who wanted to trick pacman into believing imagemagick was installed, so that he could install inkscape. I just told him he didn't understand the purpose of a package manager and that he really had to make a package for his custom imagemagick. I just make exceptions in extreme cases where : - the application is configured by source - it is actively developed and using latest code is fine or even recommended - it installs two files (one binary and one man page) - it isn't a dependency of anything else Anyway I guess we could argue a long time on this subject. In the end, it's a bit a matter of taste.
participants (3)
-
Pierre Chapuis
-
Ray Kohler
-
Xavier