Arch Linux User Repository

PKGBUILD source, issue tracker and PR -> https://github.com/arch-noob/docear

As of Jun 10, 2018 Docear is Deprecated by the author.

We currently do not have the funding and time to continue the development of Docear,
or giving support. This also means that we cannot fix any bugs that might exist
in the current version of Docear.

https://docear.org/software/download/

v1.1 is out http://www.docear.org/software/download/ Can you please update the package? Thanks!

@cfr42 thx for the reply, I'll comment it out but wont bump the pkgrel

The same is true of other packages. If you use makepkg, you find this out and you remove the directories yourself. It is standard procedure. I don't want PKGBUILDs doing this for me and I've never seen another package do so. Even though I've made plenty of packages where I needed to remove the old stuff to get it to work. This is Arch. You don't need to - and ought not to - do this stuff as a packager. It is the user/admin's job. People who use helpers such as yaourt knowingly opt into having this stuff done by the helper. People who use makepkg do so because they to know what is going on and to control the process. Your job is not to smuggle in the functionality of yaourt by the back door. I commented out those lines before I made the package. Worked fine. Of course, deleting stale directories is part of my work flow. I choose to manage it manually. If I wanted it done for me, I'd use yaourt.

@cfr42 Well, if you build it manually by using command "makepkg -si" and do not use yaourt to help you do that, and you keep the build directory for next manually update, then you may run into trouble without that command. In the tarball of docear_linux, there is a directory named like docear-1.0.3.1_stable_buildblahblahblah, and you can know it only by extracting it manually and checking it. To get rid of it, I used wildcard to rename the fking directory as docear-${pkgver}. As I said, if you build it in an old build dir, then trouble comes. I used to use _VERSION to match 1.0.3.1_stable_buildblahblahblah and it's pretty annoying. In a word, it's a workround, and it's a bit dangerous if someone screw it up. If you have a better way to make sure src dir is clean, let me know it. or should I just use: find ${srcdir} -maxdepth 1 -mindepth 1 -type d -exec rm -r {} \; to prevent potential danger?

I am not sure that build() should be doing this: find ./ -maxdepth 1 -mindepth 1 -type d -exec rm -r {} \; I know why this is done - I just don't think it is any business of a PKGBUILD to do it. I can't find any specific guidance in the wiki on this. It certainly is not something listed as a function which should be done but there's nothing definitely saying it ought not be done that I can see. This seems potentially dangerous to me. Admittedly, it is only dangerous if people do rather non-standard, and arguably daft, things. But people frequently do things you don't expect, including daft ones. Indeed, many of us are included in both the set of those who do such things and the set of those who regard those things as daft.

SourceForge has now been updated with the latest stable build.

Those devs still haven't uploaded the latest 1.0.1 stable to sourceforge, so I'll keep this package out-of-date. Anyone wants to update can install it manually.

I can confirm, SourceForge has now been updated with the latest stable build.

I removed my previous comment because I was quick off the mark. Someone from Docear responded to my request for fixed links by saying that they would update sourceforge promptly. I am hoping that by the time anyone reads this, sourceforge will already be updated and we'll all be able to use the stable 1.0 easily. Thanks, Dom.