On Tue, Oct 11, 2016 at 8:03 PM, Jason L Tibbitts III tibbs@math.uh.edu wrote:

...

...

...

...

...

"MV" == Mattia Verga mattia@fedoraproject.org writes:

MV> - I've upgraded the source to latest svn from Github. From packaging MV> guidelines, when using github for downloading a specific commit, MV> the source url should be: MV> Source0: MV> https://github.com/OWNER/%%7Bname%7D/archive/%%7Bcommit0%7D.tar.gz#/%%7Bname... MV> but such a link will download a source named MV> %{name}-%{commit0}.tar.gz (with full commit in the name instead of MV> shortcommit). Is there an error in guidelines, or am I missing MV> something?

It's not an error; it's just that there's no way to get the tarball name we want out of github. The portion after '#/' just has to match whatever you name the tarball after you download it, so that rpmbuild can find it.

%{url}/archive/%{commit0}/%{name}-%{shortcommit0}.tar.gz

Still, nothing really cares what the tarball is named as long as it's there. To be fair I don't know why there's such emphasis on having %name in the tarball name. I'll try to remember to bring that up at a packaging committee meeting at some point.

Github does now provide an easier way for releases which were tagged, though; that change will be going into the guidelines soon. (As soon as I can get around to it, that is.)

%{url}/archive/%{version}/%{name}-%{version}.tar.gz

MV> The font is present in the sources, but it's not installed in the MV> system (the file is not packaged). So, is it ok?

As long as the file isn't present in the binary package and can legally be distributed (since it would still be in the src.rpm) then there is no need to remove it.

MV> About bundling libraries, rawtherapee uses a custom patched version MV> of Klt for building, plus a heavy patched version of dcraw. Dcraw MV> bundling has been discussed before [4] and FPC ticket was closed. In MV> the .spec file I can see a "Provides: bundled(dcraw)". Should I MV> manage Klt bundling like that, with a "Provides" declaration?

Well, the bundling guidelines tell you exactly what you need to do: http://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_and_Duplication_...

Basically, contact upstream, try to eliminate any bundling, and otherwise do "Provides: bundled(whatever) = version".

• J<

---

packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org

Hi,

On Ter, 2016-10-11 at 13:03 -0500, Jason L Tibbitts III wrote:

...

...

...

...

...

"MV" == Mattia Verga mattia@fedoraproject.org writes:

MV> - I've upgraded the source to latest svn from Github. From packaging MV>   guidelines, when using github for downloading a specific commit, MV>   the source url should be: MV> Source0: MV> https://github.com/OWNER/%%7Bname%7D/archive/%%7Bcommit0%7D.tar.gz#/%%7Bnam e}-%{shortcommit0}.tar.gz MV> but such a link will download a source named MV> %{name}-%{commit0}.tar.gz (with full commit in the name instead of MV> shortcommit). Is there an error in guidelines, or am I missing MV> something?

It's not an error; it's just that there's no way to get the tarball name we want out of github.  The portion after '#/' just has to match whatever you name the tarball after you download it, so that rpmbuild can find it.

Still, nothing really cares what the tarball is named as long as it's there.  To be fair I don't know why there's such emphasis on having %name in the tarball name.  I'll try to remember to bring that up at a packaging committee meeting at some point.

Github does now provide an easier way for releases which were tagged, though; that change will be going into the guidelines soon.  (As soon as I can get around to it, that is.)

https://github.com/OWNER/%%7Bname%7D/archive/%%7Bcommit0%7D.tar.gz#/%%7Bname...

could be simplified to :

https://github.com/OWNER/%%7Bname%7D/archive/%%7Bcommit0%7D/%%7Bname%7D-%%7B...

if you update guidelines with it, I would be grateful.

Thanks,