Re: [ELN] How to handle RHEL-specific changes when it fails in ELN?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 21, 2021 at 4:36 AM Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote:
>
> On Tue, Jan 19, 2021 at 6:49 AM Fabio Valentini <decathorpe@xxxxxxxxx> wrote:
> >
> > On Tue, Jan 19, 2021 at 12:22 AM Josh Stone <jistone@xxxxxxxxxx> wrote:
> > >
> > > On 1/16/21 3:21 PM, Nico Kadel-Garcia wrote:
> > > > On Sat, Jan 16, 2021 at 4:54 PM Kevin Kofler via devel
> > > > <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > > >>
> > > >> Miro Hrončok wrote:
> > > >>> See also:
> > > >>> https://src.fedoraproject.org/rpms/rust-bootupd/c/c6cf7f6492e0d943e8471f86719df89eed587f6a?branch=master
> > > >>
> > > >> This is a blatant violation of Fedora packaging guidelines and ought to be
> > > >> reverted immediately.
> > > >>
> > > >>         Kevin Kofler
> >
> > (snip)
> >
> > > > And where and how, precisely, does "rhel require this". Having the
> > > > provenance of the source tarballs or git repos is wise and sensible,
> > > > and random tarballs with no provenance are a problem for everybody, so
> > > > that part is a good idea. But I'm not aware of it as a requirement. Is
> > > > anyone else?
> > >
> > > It's a softer "requires", as in: RHEL is not shipping rust2rpm nor the
> > > mass of rust-*-devel packages, so vendoring is the way.
> >
> > That might be so, but it's not a valid reason to build packages this
> > way in fedora, where all the required dependencies should be present
> > already.
> > Additionally, missing instructions on how to build the "vendor"
> > tarball, missing License information for the vendored crates, and
> > missing "bundled()" provides are *definitely* against Packaging
> > Guidelines.
> >
> > Fabio

(snip)

> I see a "Source1" tarball from github. If a github published archive
> isn't reasonable for a Source tarball, there are a *lot* of other
> .spec files that would need to be rejected.
>
> Some of the other logic about this is peculiar, but that particular
> "including a separate tarball" part looks  legal in and of itself. The
> Samba and Subversion and Emacs SRPM's, for example, have included
> separate tarballs for years.

You misunderstand me ... Using multiple source tarballs is perfectly
fine. I did not claim otherwise.
And since the vendor tarball is provided by upstream in this case, the
"missing instructions for how to build the vendor tarball" point is
moot.
However, the other issues regarding bundled libraries remain (wrong
resulting License tag, missing License breakdown in the .spec, missing
"bundled()" Provides).

Fabio
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux