The now undocumented --forcever option may be helpful. I think we want to document this for 3.1.1.

Thank you for the tip.

I understood what exactly I don`t like: when I want to quickly install something from source, I use yaourt (in fact I have 'alias p="LANG=C yaourt"'). It will update VCS PKGBUILDs and automate everything that is possible. I use makepkg itself only when I want to edit or write a PKGBUILD. New makepkg tries to be more self-sufficient. Maybe it is good for those who use makepkg and don`t use versionpkg and yaourt (are there any?), but I think that this feature makes more harm than behoof if usage of new makepkg is more difficult than old makepkg with combination of versionpkg. Currently makepkg can`t even replace versionpkg.

I don`t follow pacman-dev mailing list. Can you point me to rationale of this feature? Was there an idea to replace versionpkg, or only to copy some code from it to makepkg?

In what way can makepkg not replace versionpkg?

I hate yaourt. :) It makes people completely skip over understanding of makepkg and friends, but that is my personal issue.

I don't use yaourt, so this new feature was great for me. What are we missing from versionpkg that would need to be implemented?

And, for what it's worth, there have been countless times when users were not even aware of the existence of versionpkg. Look at any -svn or -cvs pkgbuild in aur and you'll find comments from users asking for a pkgver bump. So yes, I'd say there are plenty of users that don't use (or know about) versionpkg.

> It makes people completely skip over understanding of makepkg and friends, but that is my personal issue.
This is not the reason for not using yaourt by yourself.

> What are we missing from versionpkg that would need to be implemented?
I used 'versionpkg -m' because if build fails with 'versionpkg' pkgver would be reverted. This is not the case with makepkg 3.1, so this option is not needed anymore. (I hope reverting pkgver will not be ported to makepkg.)
So we miss only the ability not to update pkgver. This is really usefull.
>I don't use yaourt
May I ask you? How do you build packages from AUR? Do you use aurdownload? And if you want to build package from archlinux CVS? Do you have /var/abs and use GNU find?

> The now undocumented --forcever option may be helpful. I think we want to document this for 3.1.1.
It is not working as we need. After running "makepkg --forcever N" pkgver in PKGBUILD changes from M to N, but build process continues with pkgver=M. To make changes take affect, I have to run "makepkg --forcever N", stop it, then run "makepkg --forcever N" again. I don`t think this hidden feature should be documented in the man page while it behaves like this.

makepkg --forcever is working properly, there is just a display issue it seems.

sonata-svn PKGBUILD has pkgver=444

$ makepkg --forcever 478
==> Making package: sonata-svn 444-1 (Sun Jan 13 11:52:12 MST 2008)
==> Checking Runtime Dependencies...
==> Checking Buildtime Dependencies...
...
...
Checked out revision 478.
...
...
==> Finished making: sonata-svn (Sun Jan 13 11:52:31 MST 2008)
$ ls
PKGBUILD pkg sonata-svn-478-1-i686.pkg.tar.gz sonata-svn.install src

So the only problem is that the very first line of output from makepkg is displayed wrong.

> And, for what it's worth, there have been countless times when users were not even aware of the existence of versionpkg. Look at any -svn or -cvs pkgbuild in aur and you'll find comments from users asking for a pkgver bump. So yes, I'd say there are plenty of users that don't use (or know about) versionpkg.

How did they know about the existence of makepkg? Maybe we have incomplete documentation? If they don`t know about versionpkg maybe they don`t know about other tools to work with AUR, such as tools for searching, aurdownload, aurvote or equivalents? In this case it is better to point them to a wiki page then to modify main developers tools for them.

I`m not against devel_check() in makepkg, but I`m sure there should be a way to trigger it.

> So the only problem is that the very first line of output from makepkg is displayed wrong.

I`m sorry, I picked up random svn package from AUR (arch-repodiff-svn) and it was badly written so I made a mistake.

makepkg and pacman are officially supported utilities. One learns of them simply by using Arch. yaourt, aurbuild, aurdownload, and even, until this point, versionpkg, are not official tools.

I see mention of "it's better to do X than to modify the main developers' tools" - surprise, we _are_ the main developers, and we've modified the tools how we see fit.

makepkg will autobump the version because that is the common case. forcever is undocumented, but will cover this issue in full.

You do, however, mention the -m option which is interesting. What do you guys think (Dan, Scott, et al)?

> I see mention of "it's better to do X than to modify the main developers' tools" - surprise, we _are_ the main developers, and we've modified the tools how we see fit.

I meant that most packages which can be automatically updated with devel_check() are in AUR.

While looking for packages in /var/abs which have _svntrunk in their PKGBUILDs I have found another problem: look into extra/office/netpbm/PKGBUILD. Makeworld will make a wrong package, and running makepkg on it with --forcever=`extract_pkgver_from_pkgbuild` seems to be an ugly solution.

There is also nautilus-locked-folder in community.
What should makeworld do if it has to build updateable package?

What do you think about adding extra option to the PKGBUILD so that by default makepkg will check for updates, but if it is set (in netpbm, nautilus-locked-folder, kdeicons-oxygen-svn and maybe others, or if I set it in my PKGBUILD while debugging it (in this case commandline option may be better)) makepkg will not? This will be helpfull for automation.

> What do you think about adding extra option
If this option will be introduced it might be needed to add a commandline option to force devel_check().
In this case '-m' will be great because if something like '!devel_check' is set in PKGBUILD, then most likely makepkg can`t update pkgver by itself, so the human will get control as soon as possible without hitting Ctrl+C.

> In this case '-m' will be great
Not so great: it might be better to print guessed pkgver rather then to apply it to the pkgbuild.

Here are two patches that should help.

1. Introduces a --holdver option that prevents the pkgrel from being automatically bumped.
2. Documents the --holdver option in both --help and the man page.

This keeps the --forcever option hidden from the user because, well, it's not very useful and it can now be accommodated by setting the pkgrel in the PKGBUILD and running makepkg --holdver.

Another possible problem: is it alright that if --forcever is specified pacman will not exit with "==> ERROR: A package has already been built. (use -f to overwrite)" if this`s true?

This was also fixed in the patch. (Remember: --forcever was originally a hidden option, so I didn't plan on users typing this manually.)

http://projects.archlinux.org/git/gitweb.cgi?p=pacman.git;a=commit;h=916e226b7839e38d9245ecbef396eb5ba5b6a224

http://projects.archlinux.org/git/gitweb.cgi?p=pacman.git;a=commit;h=916e226b7839e38d9245ecbef396eb5ba5b6a224