[Fedora-packaging] DRAFT: SourceURL addition/clarification - Git Hosting Services
Gerald B. Cox
gbcox at bzb.us
Fri Jun 26 18:12:41 UTC 2015
On Fri, Jun 26, 2015 at 10:49 AM, Rich Mattes <richmattes at gmail.com> wrote:
> The best practices for using git aren't going to be universally
> applied by all upstreams. They're just not. People make mistakes,
> people decide to do things their own way, and I don't think it's our
> responsibility or problem as Fedora packagers to police upsteams for
> git tagging like it is for more important things like LICENSE files.
> ...
>
> Yikes. Not allowed by whom? Is Fedora now the git police? Does an
> upstream even care what Fedora thinks of its policies?
>
ROFL...Rich, excellent point. I put that in because there had been some
feedback concerning re-tagging. If we're going to do something about it
I think it is more helpful to try to educate upstream than to just issue
a blanket ban in Fedora. I have no problem whatsoever in changing that
instruction. I do think it is helpful to put into the Spec file some type
of
comment that a particular upstream is re-tagging, if we believe it is
worthwhile.
I'm still trying to understand the real harm to Fedora if somehow a
re-tagged
package slips through.
> The biggest complaint I have with this draft is that it introduces a
> lot of extra unnecessary work for packagers. Anyone packaging
> software coming from a git repository first has to figure out if
> they're able to use tags or not, based on a very opaque criteria. How
> do you know that a project is moving tags? Can you audit it before
> you package it? How much work does that take? Further, once you do
> package something, how do you make sure that the tag you used in your
> source URL doesn't change? Do you need to check your source checksum
> vs upstream when making point releases? Or do you check it monthly or
> weekly? Is there any way to automate this process for people that
> maintain a lot of packages?
>
Good point, again, I put that text in there because some people were
concerned
about the harm to Fedora with re-tagging. I believe this would mainly come
up
in the package review process, you would know if someone had re-tagged
because
the checksum wouldn't match when fedora-review did the check. Yes, that
would only be for that point in time. It wasn't my intent to have the
packager
continually audit to check for re-tagging.
> The current guidelines are good for a number of reasons, including
> * There is **one** way to get releases from github
> * There are code snippets to copy/paste to make life easier
> * The rpm source URL will ALWAYS point to the code you used to generate
> the RPM
>
> That still holds true in my Draft; but it makes clear that we're talking
about Git, not just
GitHub.
> I don't think your proposed guidelines are an improvement to the
> current guidelines. They're creating a lot of extra work and
> complexity just to make things look nicer in some cases.
>
My intent was to clarify the current guidelines and bring them up-to-date
and clear
up some misleading statements.
>
> > As I mentioned previously, the commit hash is part of the generated
> archive. That information
> > is never lost, regardless of what upstream does with the Git Tag.
>
> How are you generating archives? If you generate them with a url like
> github.com/$USER/%{name}/archive/%{name}-%{tag}.tar.gz2
>
> , then there's
> no commit hash anywhere in the archive (at least that I can see.) If
> you're generating the archives a different way, you need to include an
> example of how to do so in your guideline draft.
>
You obtain the commit hash via git get-tar-commit-id < $tar_file_name
Remember to execute this command against the tar file and not the
compressed archive.
> The "Git Tags"
> section of the draft provides no guidance for how to actually assemble
> a source URL from a git tag. It just says that tags can be formatted
> differently project to project, and then goes on to talk about tags
> moving.
>
I thought it was intuitive and didn't need an example... but I have no
problem whatsoever
with adding an example if folks think it would be helpful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/packaging/attachments/20150626/16fb99d9/attachment.html>
More information about the packaging
mailing list