[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