Package Details: scitopdf 0.7.2-1

Git Clone URL: https://aur.archlinux.org/scitopdf.git (read-only, click to copy)
Package Base: scitopdf
Description: Script to quickly fetch scientific papers from Sci-Hub or Libgen.
Upstream URL: https://github.com/dougy147/scitopdf.git
Licenses: GPL3
Conflicts: scitopdf-git
Provides: scitopdf
Submitter: dougy147
Maintainer: dougy147
Last Packager: dougy147
Votes: 2
Popularity: 0.000000
First Submitted: 2022-06-16 10:28 (UTC)
Last Updated: 2024-09-05 08:24 (UTC)

Dependencies (1)

Required by (0)

Sources (1)

Latest Comments

dougy147 commented on 2024-09-06 07:34 (UTC)

Thanks for your feedback @m040601, This is an interesting option for both users and servers. I opened an issue on the GitHub repo about it, feel free to track that there!

m040601 commented on 2024-09-04 16:09 (UTC) (edited on 2024-09-04 16:21 (UTC) by m040601)

Thanks for the continuing work and improvements.

Just some feedback for you. This tool is really gold. I use it for academic articles in both the humanities and tech/science. It it sooooo usefull to get very old papers out of print.

I am actually using "scitopdf-git".

It has been working flawlessly. No dns problems, no blocks. Always finds a way.

This option is "brutal"

       -l, --list bibliography_file
              Download multiple papers referenced in a bibliography file. The
              bibliography file is any text file ........

Since I discovered it, I've been using and abusing it with simple lines of URLs or DOIs in plain text files.

Sometimes I push it to hard and overload it with too many downloads at the same time.

Some sci-hub servers seem then to impose some kind of restriction. They seem to limit my speed if I do too many consecutive downloads in a very short time. Especially if my internet connection is "too fast".

But if I pause a bit, stop, wait and resume it later, it works again.

That is of course not a problem of scitopdf, but a (well intentioned) restriction of the server.

This got me thinking.

Maybe there could be an extra optional flag to use with the "-l --list" flag ?

Something to self limit yourself or pause a bit between requests ?

Like, for example:

-w or --wait (seconds) 

That is. If doing multiple consecutive requests, wait and pause xyz seconds/minutes between them.

What do you think ?

dougy147 commented on 2023-11-09 13:45 (UTC) (edited on 2024-03-13 09:55 (UTC) by dougy147)

@m040601, @Antiz

First of, thanks for your insightful remarks. I hope your efforts to guide me towards compliance regarding the AUR guidelines are fruitful. Here is what I did:

You should not be using "/usr/local" in Archlinux.

Corrected this and set PREFIX to /usr in PKGBUILD. As stated here: "All Arch Linux packages should use the /usr directory."

If you want a more stable PKGBUILD on Archlinux, maybe you could wait a little longer, until you have polished it more, and are certain of no big bugs. Than do a proper "release" on github. [...] This PKGBUILD should be actually called "scitopdf-git" and not "scitopdf" according to the AUR guidelines [...] Its source is not a release xxx-number.tar.gz that gets pulled from github. As there are no releases on github.

As the script is stable, I created a release on GitHub (v0.6.5). PKGBUILD points towards the latest release tag and will not be updated everytime a minor change is made.

[...] That would have been true if that package had a proper "pkgver()" function, but it does not.

The pkgver() function has been added to PKGBUILD and will follow the last annotated tag in the development repository.

You are still missing the LICENSE which you have on the repo and should end up in [...]

LICENSE has been correctly renamed in the GitHub repository. Thanks for noticing that!

And eventually the README and future docs. That is if the man page does not contain everything neeeded and is not up to date.

I don't find any doc about this, is there something wrong with the man page?

Also note that this package is now conflicting with scitopdf-git to avoid potential troubles on users end.

Finally, I am not against removing this repository if judged needed. Otherwise, if there are any other changes to be done, I will pursue efforts to guidelines compliance.

Again, thank you for time spent inspecting that package.

Antiz commented on 2023-09-19 13:26 (UTC) (edited on 2023-09-19 13:29 (UTC) by Antiz)

@m040601, dougy147:

This PKGBUILD should be actually called "scitopdf-git" and not "scitopdf" according to the AUR guidelines, https://wiki.archlinux.org/title/Arch_package_guidelines#Package_naming

True

You are still missing the LICENSE which you have on the repo and should end up in /usr/share/licenses/scitopdf/LICENSE

This software is licensed under the GPL3 license so it does not need to copy the license locally as the said license is already provided by the [licenses package(https://wiki.archlinux.org/title/PKGBUILD#license). See https://wiki.archlinux.org/title/PKGBUILD#license

You dont need to keep changing the "pkgver" for this PKGBUILD,when you do some development on github. You dont have to come here on AUR and update the PKGBUILD yourself. [...] Because it is a "-git" type of PKGBUILD it doesnt care about "versions" or what you do on github. If it detects that you have done something on the master repo on github, it automaticaly asks the AUR user to update. And uses git clone to pull those latest commits.

That would have been true if that package had a proper "pkgver()" function, but it does not. See: https://wiki.archlinux.org/title/VCS_package_guidelines#The_pkgver()_function

Despite being maintained by the developer of the software itself, this package does not respect the packaging guidelines and is a duplicate one (since this package seems to have been uploaded on the AUR first), which is not allowed.

As explained in this comment, I don't see the point working on making this package compliant with the package guidelines to replace the current scitopdf-git package when the latter is already properly packaged. I advice making a merge-request from this package to the scitopdf-git package and ask the current maintainer of it to add you (dougy147) as a co-maintainer if you want to collaborate on maintaining it.

m040601 commented on 2023-09-19 11:53 (UTC) (edited on 2023-09-19 12:01 (UTC) by m040601)

You dont need to keep changing the "pkgver" for this PKGBUILD,when you do some development on github. You dont have to come here on AUR and update the PKGBUILD yourself.

-pkgver=0.6.3
+pkgver=0.6.4

5 to 6, 7 to 8 etc

It's useless. Because you have neither "versions" nor "releases" on github.

https://wiki.archlinux.org/title/VCS_package_guidelines

This PKGBUILD uses git to pull from master.

It automatically makes sure the user as the latest software on his PC as you have made changes on github.

Because it is a "-git" type of PKGBUILD it doesnt care about "versions" or what you do on github. If it detects that you have done something on the master repo on github, it automaticaly asks the AUR user to update. And uses git clone to pull those latest commits.

https://wiki.archlinux.org/title/Arch_package_guidelines

https://wiki.archlinux.org/title/PKGBUILD

https://wiki.archlinux.org/title/Creating_packages

m040601 commented on 2023-09-19 11:00 (UTC) (edited on 2023-09-19 11:01 (UTC) by m040601)

@dougy147

You are still missing the LICENSE which you have on the repo and should end up in

/usr/share/licenses/scitopdf/LICENSE

And eventually the README and future docs. That is if the man page does not contain everything neeeded and is not up to date.

/usr/share/doc/scitopdf/README
/usr/share/doc/scitopdf/ADVANCED.md bla bla etc

m040601 commented on 2023-09-19 10:46 (UTC) (edited on 2023-09-19 11:03 (UTC) by m040601)

This PKGBUILD should be actually called "scitopdf-git" and not "scitopdf" according to the AUR guidelines, https://wiki.archlinux.org/title/Arch_package_guidelines#Package_naming

Its source is not a release xxx-number.tar.gz that gets pulled from github. As there are no releases on github.

It just uses git clone to build the package.

Unfortunately someone else also made a "scitopdf-git" PKGBUILD and took that name, https://aur.archlinux.org/packages/scitopdf-git.

It's useless and confusing to end users to have duplictated PKGBUILDs on the AUR doing the same thing exactly.

I left a message there, asking the maintainer to consider deleting the PKGBUILD ( 1995parham ) "scitopdf-git" .

So that this one (dougy147) can use that name and be renamed to "scitopdf".

It seems to be the wise thing do to since dougy147 is both the developer of the tool and maintains the PKGBUILD.

dougy147 commented on 2022-06-21 08:58 (UTC)

Insightful remarks, proper release will come soon

m040601 commented on 2022-06-19 22:51 (UTC) (edited on 2022-06-19 23:09 (UTC) by m040601)

Interesting tool. And thanks for creating it and coming here to work on this PKGBUILD. The way you have it right now, this is the end result,

$ pacman -Ql scitopdf

scitopdf /usr/
scitopdf /usr/local/
scitopdf /usr/local/bin/
scitopdf /usr/local/bin/scitopdf
scitopdf /usr/local/man/
scitopdf /usr/local/man/man1/
scitopdf /usr/local/man/man1/scitopdf.1.gz

"/usr/local".

This is wrong according the Arch PKGBUILD guide lines. You should not be using "/usr/local" in Archlinux.

You are probably doing this mistake, because you are blindly following what the Makefile, https://github.com/dougy147/scitopdf/blob/master/Makefile in the original repo contains.

That Makefile is a generic file for a generic Linux installation. AUR PKGBUILD's are specific to Archlinux. You are supposed to study that Makefile and understand what is needed to be done, for the Archlinux PKGBBUILD. not blindly copy it.

See how another Arch users does it, https://aur.archlinux.org/packages/scitopdf-git, and correct yours. You could actually coordinate with him. No need for two different maintainers for the same tool.

You also named your PKGBUILD "0.3.r124.729695f-1", which to me seems that your intention is simply pull whatever the lastest commits you have on github. In that case, it should be called "XXX-git" . There is no need for that, as there is already the other "scitopdf-git".

If you want a more stable PKGBUILD on Archlinux, maybe you could wait a little longer, until you have polished it more, and are certain of no big bugs. Than do a proper "release" on github. Something like "version "1.0". And then start with a "pkgver=1.0" or "1.1", etc in AUR. Not version 0.3345345XXXXXX.

Only than, does it make sense to have a "stable" version of "scitopdf" in AUR. One that "pulls" from the releases, not the latest git commmits.