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 befo
> 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 are
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 again:
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 ever
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 fo
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 sens
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 tim
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 a
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 wit
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,
thou
> 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 mo
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
> th
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
https://github.com/rpm-software-manageme
> 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 b
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 people
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 additi
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
d
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 o
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 basica
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 cl
> "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 th
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
> > mo
> 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 ma
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 pack
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 for
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 for local builds. It
is possible that some of this could be alle
42 matches
Mail list logo
