[aur-dev] Display of alternative source name instead of URL on packages' web pages
Hello. An alternative source name set in variable 'source' of PKBDUILD is replacing the URL in packages' web pages, see e. g. https://aur.archlinux.org/packages/cantata-git/ where section "Sources (1)" states "cantata-git" instead of "git+https://github.com/CDrummond/cantata.git". I'm not absolutely sure whether this behaviour may eventually be expected but actually don't think it makes a lot of sense. So wouldn't it be better to have the URL displayed regardless of an alternative source name is set or not? Regards, Peter Mattern
On Sun, 25 Oct 2015 at 17:29:42, Peter Mattern wrote:
Hello.
An alternative source name set in variable 'source' of PKBDUILD is replacing the URL in packages' web pages, see e. g. https://aur.archlinux.org/packages/cantata-git/ where section "Sources (1)" states "cantata-git" instead of "git+https://github.com/CDrummond/cantata.git".
I'm not absolutely sure whether this behaviour may eventually be expected but actually don't think it makes a lot of sense. So wouldn't it be better to have the URL displayed regardless of an alternative source name is set or not?
Yes, this behavior is intended and I personally think it makes sense. The semantics of sources the form filename::url is: Obtain the file from the given URL but change the source name to the given file name. The best way to replicate this semantics in HTML is to use the URL as link target and use the name as link label.
Regards,
Peter Mattern
Yes, this behavior is intended and I personally think it makes sense. The semantics of sources the form filename::url is: Obtain the file from the given URL but change the source name to the given file name. The best way to replicate this semantics in HTML is to use the URL as link target and use the name as link label.
Yes, I guess in the case of filename::url this makes perfect sense. In the example of Peter though, it's more obfuscating the git url. One way to fix this of course is to not specify an alternative name: source=("git+https://github.com/CDrummond/cantata.git") But this is still an invalid url. If the url starts with "git+", that should be stripped at least from the href. I would suggest to use: <a href="https://github.com/CDrummond/cantata.git">git+https://github.com/CDrummond/cantata.git</a> Chris -- echo mailto: NOSPAM !#$.'<*>'|sed 's. ..'|tr "<*> !#:2" org@fr33z3
On Tue, 27 Oct 2015 at 10:03:02, Christoph Gysin wrote:
Yes, this behavior is intended and I personally think it makes sense. The semantics of sources the form filename::url is: Obtain the file from the given URL but change the source name to the given file name. The best way to replicate this semantics in HTML is to use the URL as link target and use the name as link label.
Yes, I guess in the case of filename::url this makes perfect sense. In the example of Peter though, it's more obfuscating the git url.
I don't quite understand this sentence because in Peter's example, the source is of the form filename::url.
One way to fix this of course is to not specify an alternative name:
source=("git+https://github.com/CDrummond/cantata.git")
But this is still an invalid url. If the url starts with "git+", that should be stripped at least from the href.
URLs referring to a protocol other than HTTP/HTTPs are not invalid.
I would suggest to use:
<a href="https://github.com/CDrummond/cantata.git">git+https://github.com/CDrummond/cantata.git</a>
So you are suggesting to replace the link target with a link to another URL? That is not a good idea because we cannot simply assume that they mean the same thing in general. Also, if your browser does not know how to handle the git+https protocol, that is a client configuration issue and not a server issue (if you consider that an issue at all).
Chris -- echo mailto: NOSPAM !#$.'<*>'|sed 's. ..'|tr "<*> !#:2" org@fr33z3
On 27/10, Lukas Fleischer wrote:
I would suggest to use:
<a href="https://github.com/CDrummond/cantata.git">git+https://github.com/CDrummond/cantata.git</a>
Also, if your browser does not know how to handle the git+https protocol, that is a client configuration issue and not a server issue (if you consider that an issue at all).
Well, the vcs+url thing is makepkg-specific and won't work with eg git either though. -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
On Tue, 27 Oct 2015 at 17:21:43, Johannes Löthberg wrote:
On 27/10, Lukas Fleischer wrote:
I would suggest to use:
<a href="https://github.com/CDrummond/cantata.git">git+https://github.com/CDrummond/cantata.git</a>
Also, if your browser does not know how to handle the git+https protocol, that is a client configuration issue and not a server issue (if you consider that an issue at all).
Well, the vcs+url thing is makepkg-specific and won't work with eg git either though. [...]
At least git+ssh:// and ssh+git:// work fine with Git. From transport.c in the Git source tree: } else if (!is_url(url) || starts_with(url, "file://") || starts_with(url, "git://") || starts_with(url, "ssh://") || starts_with(url, "git+ssh://") || starts_with(url, "ssh+git://")) { /* * These are builtin smart transports; "allowed" transports * will be checked individually in git_connect. */ git+https probably doesn't work by default but I do not see why we should add a special case for that and pretend that the URL "works as a website" while it is intended to be a Git clone URL.
git+https probably doesn't work by default but I do not see why we should add a special case for that and pretend that the URL "works as a website" while it is intended to be a Git clone URL.
We are doing the same with the URL for the package itself though: Git Clone URL: https://aur.archlinux.org/cantata-git.git (read-only) Maybe it would make sense to just turn these links into git clone commands that can be copy pasted, like: git clone https://aur.archlinux.org/cantata-git.git and git clone https://github.com/CDrummond/cantata.git Chris -- echo mailto: NOSPAM !#$.'<*>'|sed 's. ..'|tr "<*> !#:2" org@fr33z3
On Mon, Oct 26, 2015 at 3:17 PM, Lukas Fleischer
Yes, this behavior is intended and I personally think it makes sense. The semantics of sources the form filename::url is: Obtain the file from the given URL but change the source name to the given file name. The best way to replicate this semantics in HTML is to use the URL as link target and use the name as link label.
If anything, perhaps sources in the form "url" should also be stripped --purely for the sake of consistency. ;) The filename (or VCS folder) will be the last component of the url -- not the whole url. So when looking at the sources in HTML, perhaps the last component of the url should be the link label. In the case of a git url, the ".git" at the end should also be removed. -- Eli Schwartz
participants (5)
-
Christoph Gysin
-
Eli Schwartz
-
Johannes Löthberg
-
Lukas Fleischer
-
Peter Mattern