Dne 05. 11. 18 v 16:22 Justin Forbes napsal(a):
> It
> is possible that some of this could be alleviated with a fairly simple
> change to mock.
There is no need for a change in Mock. Mock can consume modules for looong
time. You can put in mock config something like:
# This is executed just
> Please do not drag Go into this if you want to handwave Go away
> problems. Yes modules will be useful in Go but only to blow away in EPEL
> the rotten Go codebase RHEL ships.
>
> But anyway, since you referred to GO.
>
> Go is the perfect example of why bundling as a general approach does not
On Mon, Nov 12, 2018 at 11:50 AM Randy Barlow
wrote:
>
> On Mon, 2018-11-12 at 09:04 -0500, Neal Gompa wrote:
> > It is not. Arguably, this check should be blocking across the board.
> > I
> > personally would rather have this check earlier than Bodhi (mark
> > builds in Koji as failed if they
On Mon, 2018-11-12 at 09:04 -0500, Neal Gompa wrote:
> It is not. Arguably, this check should be blocking across the board.
> I
> personally would rather have this check earlier than Bodhi (mark
> builds in Koji as failed if they aren't installable), but that
> appears
> to be a thing we can't do.
On Mon, 2018-11-12 at 07:43 -0500, Stephen Gallagher wrote:
> It should see that the packages won't be
> installable and once we get gating turned back on, it will enforce
> that the package cannot go to stable.
It is now possible and encouraged to voluntarily opt-in to test gating
in Bodhi
On Mon, Nov 12, 2018 at 9:02 AM Vít Ondruch wrote:
>
>
> Dne 12. 11. 18 v 13:43 Stephen Gallagher napsal(a):
> > On Mon, Nov 12, 2018 at 4:50 AM Vít Ondruch wrote:
> >>
> >> Dne 09. 11. 18 v 16:28 Stephen Gallagher napsal(a):
> >>> On Fri, Nov 9, 2018 at 9:53 AM Kevin Kofler
> >>> wrote:
>
On Mon, Nov 12, 2018 at 8:10 AM Vít Ondruch wrote:
>
>
> Dne 12. 11. 18 v 13:43 Stephen Gallagher napsal(a):
> > On Mon, Nov 12, 2018 at 4:50 AM Vít Ondruch wrote:
> >>
> >> Dne 09. 11. 18 v 16:28 Stephen Gallagher napsal(a):
> >>> On Fri, Nov 9, 2018 at 9:53 AM Kevin Kofler
> >>> wrote:
>
Dne 12. 11. 18 v 13:43 Stephen Gallagher napsal(a):
> On Mon, Nov 12, 2018 at 4:50 AM Vít Ondruch wrote:
>>
>> Dne 09. 11. 18 v 16:28 Stephen Gallagher napsal(a):
>>> On Fri, Nov 9, 2018 at 9:53 AM Kevin Kofler wrote:
Raphael Groner wrote:
> Kevin,
>> * that no package may
On Mon, Nov 12, 2018 at 4:50 AM Vít Ondruch wrote:
>
>
> Dne 09. 11. 18 v 16:28 Stephen Gallagher napsal(a):
> > On Fri, Nov 9, 2018 at 9:53 AM Kevin Kofler wrote:
> >> Raphael Groner wrote:
> >>
> >>> Kevin,
> * that no package may ever be module-only, but
> modules can only be used
Dne 09. 11. 18 v 16:28 Stephen Gallagher napsal(a):
> On Fri, Nov 9, 2018 at 9:53 AM Kevin Kofler wrote:
>> Raphael Groner wrote:
>>
>>> Kevin,
* that no package may ever be module-only, but
modules can only be used for non-default
versions.
>>> That statement doesn't make any
On Sat, Nov 10, 2018 at 9:45 PM Kevin Kofler wrote:
>
> Dridi Boukelmoune wrote:
> > If you take this compromise to an extreme then let's solve the Java
> > problem (or ) and grant an internet access
> > to builds. This way we can use vanilla maven/gradle/ivy to fetch
> > dependencies at build
Dridi Boukelmoune wrote:
> If you take this compromise to an extreme then let's solve the Java
> problem (or ) and grant an internet access
> to builds. This way we can use vanilla maven/gradle/ivy to fetch
> dependencies at build time and make sure that we can upgrade to the
> latest versions of
Le vendredi 09 novembre 2018 à 18:44 +0100, Dridi Boukelmoune a écrit :
> >
> For the Go case (and we can include Rust too) it is indeed very likely
> that, because the model is almost exclusively static linking, a leaf
> package will force the creation of dozens of devel packages only for
> the
Le vendredi 09 novembre 2018 à 10:28 -0500, Stephen Gallagher a écrit :
>
> Consider the Go case: we know that most Go packages will be statically
> linked (issues with that are a different topic), so we know they will
> work fine once built. However, if the application upstream cannot
> build
On Fri, Nov 9, 2018 at 11:20 AM Stephen Gallagher wrote:
> Consider the Go case: we know that most Go packages will be statically
> linked (issues with that are a different topic), so we know they will
> work fine once built.
How does this scale to ecosystems that *aren't* statically linked,
> Consider the Go case: we know that most Go packages will be statically
> linked (issues with that are a different topic), so we know they will
> work fine once built. However, if the application upstream cannot
> build with the latest "stable" version because of
> backwards-incompatible changes,
On Fri, Nov 09, 2018 at 05:09:24PM +0100, Tomasz Torcz wrote:
> Suprisingly, recently I've found use for modularity. It's a crutch
> for bad software (OpenShift breaking backwards compatibility) but it
> worked.
I mean, software is software. :)
> That's as an user. I'm still to discover the
On Tue, Nov 06, 2018 at 12:56:13PM -0500, Neal Gompa wrote:
> On Tue, Nov 6, 2018 at 12:26 PM Stephen Gallagher wrote:
> >
> > As a hypothetical example, maybe python-sphinx has a major
> > backwards-incompatible update that becomes the default in Fedora 30.
> > The package you maintain will only
On Fri, Nov 9, 2018 at 9:53 AM Kevin Kofler wrote:
>
> Raphael Groner wrote:
>
> > Kevin,
> >>* that no package may ever be module-only, but
> >> modules can only be used for non-default
> >> versions.
> >
> > That statement doesn't make any sense for me. Can you explain, please? How
> > should
Raphael Groner wrote:
> Kevin,
>>* that no package may ever be module-only, but
>> modules can only be used for non-default
>> versions.
>
> That statement doesn't make any sense for me. Can you explain, please? How
> should modules live without packages in background? We'd already discussed
>
Le vendredi 09 novembre 2018 à 11:21 +, Mat Booth a écrit :
>
> It's not about forcing modules onto users, it's about not forcing more
> work than necessary onto already overstretched maintainers.
Then help finish
https://pagure.io/fesco/issue/2004
and
> The advantage for packagers is just temporary, as long as the
> (supposedly) older library they still use is maintained. One day, they
> will need to move forward. This is just postponing the inevitable.
And for the same reason we have compat packages, we can't always honor
the First principle
On Thu, 8 Nov 2018 at 05:01, Kevin Kofler wrote:
> Zbigniew Jędrzejewski-Szmek wrote:
> > This is not about forcing modules unto people. The drive comes from
> > the other direction: packages want to be available only as modules,
>
> But that is exactly what I mean by "forcing modules onto
Dne 09. 11. 18 v 3:33 Kevin Kofler napsal(a):
> Neal Gompa wrote:
>> Moreover, as it stands, I don't think modularity provides any quality
>> of life improvements for packagers within Fedora (it adds extra steps
>> and makes it confusing to figure out what is maintained),
> There is one I can see
Kevin,
>* that no package may ever be module-only, but
> modules can only be used for non-default
> versions.
That statement doesn't make any sense for me. Can you explain, please? How
should modules live without packages in background? We'd already discussed this
in another thread.
> Neal Gompa wrote:
…
> But obviously, I think this is a very poor tradeoff. Helping packagers must
> not happen at the end users' expense!
>
> Kevin Kofler
+1
Can you think about a time when modules can or will (hopefully) bring benefits
to our users? Well, it's just seen as an
Neal Gompa wrote:
> Moreover, as it stands, I don't think modularity provides any quality
> of life improvements for packagers within Fedora (it adds extra steps
> and makes it confusing to figure out what is maintained),
There is one I can see in that it allows packagers to make their packages
Stephen Gallagher wrote:
> The feedback that we (Red Hat) got about SCLs that was filtered down
> to Engineering was this:
But is that feedback relevant for Fedora, as opposed to RHEL?
> 1) Customers really like having the option to install the version of
> software that their applications needs
Zbigniew Jędrzejewski-Szmek wrote:
> This is not about forcing modules unto people. The drive comes from
> the other direction: packages want to be available only as modules,
But that is exactly what I mean by "forcing modules onto people"!
> and this is a work-around to allow them to be used as
On Tue, Nov 6, 2018 at 6:06 PM Stephen Gallagher wrote:
>
>
> I find myself repeating this reply over and over again in various places...
Sorry about that.
> The feedback that we (Red Hat) got about SCLs that was filtered down
> to Engineering was this:
>
> 1) Customers really like having the
On Tue, Nov 6, 2018 at 12:26 PM Stephen Gallagher wrote:
>
> As a hypothetical example, maybe python-sphinx has a major
> backwards-incompatible update that becomes the default in Fedora 30.
> The package you maintain will only build its docs with the older Sphinx.
> Without Ursa Major, you
On Tue, Nov 6, 2018 at 11:21 AM Jason L Tibbitts III wrote:
>
> > "FW" == Florian Weimer writes:
>
> FW> Modules do not support parallel installations of different module
> FW> versions. Many SCLs are constructed in such a way that this is
> FW> possible. So I'm not sure if modules are a
> "FW" == Florian Weimer writes:
FW> Modules do not support parallel installations of different module
FW> versions. Many SCLs are constructed in such a way that this is
FW> possible. So I'm not sure if modules are a clear improvement over
FW> SCLs.
And the really fun thing is that once
On Tue, Nov 6, 2018 at 10:47 AM Florian Weimer wrote:
>
> * Nicolas Mailhot:
>
> > My current understanding of modules benefits is that they’re just
> > improved SCLs. ie something EL oriented that the average Fedora packager
> > has little interest or use for.
> >
> > Practically, being improved
* Nicolas Mailhot:
> My current understanding of modules benefits is that they’re just
> improved SCLs. ie something EL oriented that the average Fedora packager
> has little interest or use for.
>
> Practically, being improved SCLs just means:
>
> 1. rawhide has the latest version of each module
Le mardi 06 novembre 2018 à 11:05 +0100, Dridi Boukelmoune a écrit :
> > I'm with you in the sense that I too fail to see practical benefits
> > of
> > modules so far. But e.g. the java-sig says it makes their life
> > easier,
> > and it is their choice. The decision was made to proceed with
> >
> I'm with you in the sense that I too fail to see practical benefits of
> modules so far. But e.g. the java-sig says it makes their life easier,
> and it is their choice. The decision was made to proceed with
> modularity in Fedora. Once that decision was made, we cannot forbid
> packagers from
On Tue, Nov 06, 2018 at 01:54:54AM +0100, Kevin Kofler wrote:
> Fabio Valentini wrote:
> > I have to say, making core, non-leaf packages available as modules
> > only sounds like a *terrible* idea to me.
> > I don't want to have to deal with this uncooked mess if I just want to
> > do standard
Fabio Valentini wrote:
> I have to say, making core, non-leaf packages available as modules
> only sounds like a *terrible* idea to me.
> I don't want to have to deal with this uncooked mess if I just want to
> do standard packaging.
+1. And, for that matter, that goes even for standard USING, as
On Mon, Nov 5, 2018 at 5:13 PM Justin Forbes wrote:
>
> This is related to an open ticket to Release Engineering
> (https://pagure.io/releng/issue/7840) which was brought to FESCo
> (https://pagure.io/fesco/issue/2003).
Until now, I've been mostly keeping quiet about the whole modularity
thing -
On Mon, 5 Nov 2018 at 11:14, Justin Forbes wrote:
>
> This is related to an open ticket to Release Engineering
> (https://pagure.io/releng/issue/7840) which was brought to FESCo
> (https://pagure.io/fesco/issue/2003). We understand the need to
> enable this, but there is an impact to workflow
41 matches
Mail list logo
