Hi,
Handling the GitHub URL is a painful work.
Can we allow this?
https://github.com/$OWNER/$PROJECT/archive/%%7Bversion%7D.tar.gz
Thanks.
Yours sincerely, Christopher Meng
Always playing in Fedora Project
----- Original Message -----
From: "Christopher Meng" cickumqt@gmail.com To: "Discussion of RPM packaging standards and practices for Fedora" packaging@lists.fedoraproject.org Sent: Thursday, May 30, 2013 11:29:23 AM Subject: [Fedora-packaging] Can we allow such URL?
Hi,
Handling the GitHub URL is a painful work.
Can we allow this?
https://github.com/$OWNER/$PROJECT/archive/%%7Bversion%7D.tar.gz
Hi,
Any problem when applying this guideline [1]? I think it's not difficult to follow.
[1] http://fedoraproject.org/wiki/Packaging:SourceURL#Github
Kind regards, Tuan
On 05/30/2013 07:15 AM, Christopher Meng wrote:
No.
I just want to know if this way is allowed.
Taken from the URL included in the mail you're answering to:
Remember, in this syntax, $OWNER must be replaced with the github username for the project's owner, and $PROJECT must be replaced with the github identifier for the project.
Does this answer your question now?
<somehow off topic> I guess, you removed the context from the mail you were answering to just by accident, right? Please don't do, because nobody will remember every sentence in every mail. Keeping text you're answering to in the email will make it easier for others to follow your thoughts </end off topic>
On Thu, May 30, 2013 at 3:53 PM, Matthias Runge mrunge@matthias-runge.de wrote:
Does this answer your question now?
Let me speak more clearly.
Now the GitHub SourceURL guidelines[1] said:
"For the source tarball, you should use this syntax:
https://github.com/$OWNER/$PROJECT/archive/%%7Bcommit%7D/%%7Bname%7D-%%7Bver..."
Well, each time I have to %global %{commit} and {shortcommit}, I think it's boring.
Now looking at:
https://github.com/$OWNER/$PROJECT/tags
If the author has tagged the release, GitHub will offer each tag with 3 links: Zipball URL/ Tarball URL and a link to the commit of this tag.
I only discuss tarball, tarball offers this URL:
https://github.com/$OWNER/$PROJECT/archive/%%7Bversion%7D.tar.gz
So my question is that can we use this URL as the Source0 instead of the guidelines said?
Thanks.
[1]----https://fedoraproject.org/wiki/Packaging:SourceURL#Github
On 05/30/2013 10:49 AM, Christopher Meng wrote:
On Thu, May 30, 2013 at 3:53 PM, Matthias Runge mrunge@matthias-runge.de wrote:
Does this answer your question now?
Let me speak more clearly.
OK, then please provide the real world use case you are trying to package. This would give people the opportunity to check whether you case complies to the demands Fedora package need to comply to.
Ralf
Hello Christopher, hello list!
Am Donnerstag, den 30.05.2013, 16:49 +0800 schrieb Christopher Meng:
On Thu, May 30, 2013 at 3:53 PM, Matthias Runge mrunge@matthias-runge.de wrote:
Does this answer your question now?
Let me speak more clearly.
Now the GitHub SourceURL guidelines[1] said:
"For the source tarball, you should use this syntax:
https://github.com/$OWNER/$PROJECT/archive/%%7Bcommit%7D/%%7Bname%7D-%%7Bver..."
Guidelines are made to tell you the way how things are done, aren't they? This syntax is the only sane way to have a SOURCE which can be recreated randomly and verified to be pristine.
Well, each time I have to %global %{commit} and {shortcommit}, I think it's boring.
Doing this bit of copy-paste when altering %{version}, %{release} and %changelog can't be this hard. You'll need %{commit} during %prep anyways. Even when using https://github.com/$OWNER/$PROJECT/archive/%%7Bversion%7D.tar.gz. Or ask upstream to provide tar.{bz2,xz} downloads somewhere else...
Now looking at:
https://github.com/$OWNER/$PROJECT/tags
If the author has tagged the release, GitHub will offer each tag with 3 links: Zipball URL/ Tarball URL and a link to the commit of this tag.
I only discuss tarball, tarball offers this URL:
https://github.com/$OWNER/$PROJECT/archive/%%7Bversion%7D.tar.gz
So my question is that can we use this URL as the Source0 instead of the guidelines said?
I'd say "NO WAY", because tags can be created/deleted/altered by anyone having write-access to the repo. They are NOT explicitly meant to be created-once-lasts-forever or points-to-same-commit-sha-forever, so checking the tarball to be pristine might be close to impossible in the future, if the tag will be altered pointing to an other commit or be deleted. This may lead to FTBFS as well. An URL like this also _WILL_ lead to conflicting names of source-tarballs, because it's only named to the version and not to the app's name. Don't forget the naming guidelines: "When naming a package, the name should match the upstream tarball or project..."
https://fedoraproject.org/wiki/Packaging:NamingGuidelines?rd=Packaging/Namin...
So using the URL from the guidelines all will be fine, because it will create a tarball named containing the projectname, version and the definitive unique and forever-lasting commit-sha...
Thanks.
You're welcome!
[1]----https://fedoraproject.org/wiki/Packaging:SourceURL#Github
Cheers, Björn
tor 2013-05-30 klockan 11:51 +0200 skrev Björn Esser:
I'd say "NO WAY", because tags can be created/deleted/altered by anyone having write-access to the repo. They are NOT explicitly meant to be created-once-lasts-forever or points-to-same-commit-sha-forever, so checking the tarball to be pristine might be close to impossible in the future, if the tag will be altered pointing to an other commit or be deleted. This may lead to FTBFS as well. An URL like this also _WILL_ lead to conflicting names of source-tarballs, because it's only named to the version and not to the app's name. Don't forget the naming guidelines: "When naming a package, the name should match the upstream tarball or project..."
https://fedoraproject.org/wiki/Packaging:NamingGuidelines?rd=Packaging/Namin...
So using the URL from the guidelines all will be fine, because it will create a tarball named containing the projectname, version and the definitive unique and forever-lasting commit-sha...
Why is a tarball published on github less valuable than a tarball published anywhere else?
Admittedly, as you say a tag in github can be removed and reapplied again on a different commit. However, a well behaving upstream will not do this. This is not something unique to github - the same can happen on a git server somewhere else and in svn and cvs too. Also a tarball published by upstream on a separate server can be replaced with a different one if upstream is not well behaved. If you do not accept the tarball generated from the github tag published on the github server, why would you accept any source tarball published anywhere? They both can be replaced at any time by a weirdly behaving upstream. And neither will be replaced by a well behaving one.
Mattias
Quoting Mattias Ellert (2013-05-31 13:18:31)
tor 2013-05-30 klockan 11:51 +0200 skrev Björn Esser:
I'd say "NO WAY", because tags can be created/deleted/altered by anyone having write-access to the repo. They are NOT explicitly meant to be created-once-lasts-forever or points-to-same-commit-sha-forever, so checking the tarball to be pristine might be close to impossible in the future, if the tag will be altered pointing to an other commit or be deleted. This may lead to FTBFS as well.
Why is a tarball published on github less valuable than a tarball published anywhere else?
Admittedly, as you say a tag in github can be removed and reapplied again on a different commit. However, a well behaving upstream will not do this. This is not something unique to github - the same can happen on a git server somewhere else and in svn and cvs too. Also a tarball published by upstream on a separate server can be replaced with a different one if upstream is not well behaved. If you do not accept the tarball generated from the github tag published on the github server, why would you accept any source tarball published anywhere? They both can be replaced at any time by a weirdly behaving upstream. And neither will be replaced by a well behaving one.
Rearranged a bit, agree completely with Mattias. Github is no different than other places in this regard.
An URL like this also _WILL_ lead to conflicting names of source-tarballs, because it's only named to the version and not to the app's name. Don't forget the naming guidelines: "When naming a package, the name should match the upstream tarball or project..."
That guideline actually refers to name of (s)rpms not some tarball in lookaside cache, but OK I'm game...
Easily solvable. Example: Source0: https://github.com/JodaOrg/%%7Bname%7D/archive/v%%7Bversion%7D.tar.gz#/%%7Bn...
Note the ending "#/%{name}-%{version}.tar.gz".
As a bonus there's not dirhash to deal with. In the past problem with that URL has been that they didn't have static hash. That has been fixed as well I believe.
https://fedoraproject.org/wiki/Packaging:NamingGuidelines?rd=Packaging/Namin...
So using the URL from the guidelines all will be fine, because it will create a tarball named containing the projectname, version and the definitive unique and forever-lasting commit-sha...
I actually had a ticket opened at FPC[1] to update this guideline but then I haven't found time to prepare the draft. If someone would create a proposal and reopen the ticket...we might improve the situation.
Hi all again.
Now I have a package wemux[1], from tags[2] you can only see 2.2.0 version.
However, in the download center[3] of this project, we can found a newer version: 3.1.0.
So in this case what should I do?
Thanks.
[1]----https://github.com/zolrath/wemux [2]----https://github.com/zolrath/wemux/tags [3]----https://github.com/zolrath/wemux/downloads
Dne 10.6.2013 19:03, Christopher Meng napsal(a):
Hi all again.
Now I have a package wemux[1], from tags[2] you can only see 2.2.0 version.
However, in the download center[3] of this project, we can found a newer version: 3.1.0.
So in this case what should I do?
Ask upstream to push tags? It is quite common to forget to push them.
Vít
Thanks.
[1]----https://github.com/zolrath/wemux [2]----https://github.com/zolrath/wemux/tags [3]----https://github.com/zolrath/wemux/downloads -- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
packaging@lists.fedoraproject.org