On 2019-06-25, Adam Williamson wrote:
> So I'm still not confident about the story here. Let's take something
> that does follow semver: it's not going to change API compatibility as
> *often* as libgit2, but ultimately it's gonna happen. And in Rawhide,
> presumably, when a new major version come
On Tue, Jun 25, 2019 at 8:45 PM Stephen Gallagher
wrote:
>
>
> On Tue, Jun 25, 2019 at 1:34 PM Adam Williamson <
> adamw...@fedoraproject.org> wrote:
>
>> On Tue, 2019-06-25 at 13:22 -0400, Stephen Gallagher wrote:
>> > On Thu, Jun 20, 2019 at 7:49 PM Adam Williamson <
>> adamw...@fedoraproject.o
On Tue, Jun 25, 2019 at 1:34 PM Adam Williamson
wrote:
> On Tue, 2019-06-25 at 13:22 -0400, Stephen Gallagher wrote:
> > On Thu, Jun 20, 2019 at 7:49 PM Adam Williamson <
> adamw...@fedoraproject.org>
> > wrote:
> >
> > > On Fri, 2019-06-21 at 01:10 +0200, Fabio Valentini wrote:
> > > > But ... i
On Tue, 2019-06-25 at 13:22 -0400, Stephen Gallagher wrote:
> On Thu, Jun 20, 2019 at 7:49 PM Adam Williamson
> wrote:
>
> > On Fri, 2019-06-21 at 01:10 +0200, Fabio Valentini wrote:
> > > But ... if it's not for different version streams, then what *is it*
> > for? 🤔
> > > (What about the plans
On Thu, Jun 20, 2019 at 7:49 PM Adam Williamson
wrote:
> On Fri, 2019-06-21 at 01:10 +0200, Fabio Valentini wrote:
> >
> > But ... if it's not for different version streams, then what *is it*
> for? 🤔
> > (What about the plans to offer different versions of e.g. NodeJS via
> > streams? Is that wr
On Fri, Jun 21, 2019 at 5:47 PM Adam Williamson
wrote:
> On Fri, 2019-06-21 at 13:28 +0200, Adam Samalik wrote:
> > To keep the expectations of Fedora's stable ABI within a release, we
> can't
> > change the default stream of a module mind-release. I know, that's
> probably
> > clear and that's n
On Fri, 2019-06-21 at 13:28 +0200, Adam Samalik wrote:
> To keep the expectations of Fedora's stable ABI within a release, we can't
> change the default stream of a module mind-release. I know, that's probably
> clear and that's not the issue here. But building on that, at the same
> time, we can't
On Fri, Jun 21, 2019 at 1:28 PM Adam Samalik wrote:
>
>
> On Fri, Jun 21, 2019 at 12:08 AM Adam Williamson <
> adamw...@fedoraproject.org> wrote:
>
>> On Thu, 2019-06-20 at 23:48 +0200, Igor Gnatenko wrote:
>> > Hello,
>> >
>> > I just wanted to give you an update from my last discussions on
>> >
On Fri, Jun 21, 2019 at 12:08 AM Adam Williamson
wrote:
> On Thu, 2019-06-20 at 23:48 +0200, Igor Gnatenko wrote:
> > Hello,
> >
> > I just wanted to give you an update from my last discussions on
> > #fedora-modularity and other places.
> >
> > # Problems definition
> >
> > * Default modules can
20.06.2019, 22:50, "Igor Gnatenko" :
> Hello,
>
> I just wanted to give you an update from my last discussions on
> #fedora-modularity and other places.
>
> # Problems definition
>
> * Default modules can't have conflicting dependenices
> * Changing dependencies in a stream is not supported
>
> #
On Fri, 2019-06-21 at 01:10 +0200, Fabio Valentini wrote:
>
> But ... if it's not for different version streams, then what *is it* for? 🤔
> (What about the plans to offer different versions of e.g. NodeJS via
> streams? Is that wrong then, too?)
>
> Being able to offer different versions is the o
On Fri, Jun 21, 2019, 00:55 Adam Williamson
wrote:
> On Thu, 2019-06-20 at 23:48 +0200, Igor Gnatenko wrote:
> > Hello,
> >
> > I just wanted to give you an update from my last discussions on
> > #fedora-modularity and other places.
> >
> > # Problems definition
> >
> > * Default modules can't ha
On Thu, 2019-06-20 at 23:48 +0200, Igor Gnatenko wrote:
> Hello,
>
> I just wanted to give you an update from my last discussions on
> #fedora-modularity and other places.
>
> # Problems definition
>
> * Default modules can't have conflicting dependenices
> * Changing dependencies in a stream is
ath or just
throw away modularity and focus on other solutions which are not that invasive.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1677746
On Thu, Jun 13, 2019 at 9:22 PM Adam Samalik wrote:
>
> So, I'd like to discuss the libgit issue [1] [2] we're experiencing. With a
> help of a
Le 2019-06-17 22:04, Terry Bowling a écrit :
Hi
If I may, since I also represented the customer side not so long ago in
a fortunexxx company.
* Customers think we had too many repos. It is hard to find what
they need.
From a customer point of view you sidestepped the demand. Inste
On Mon, Jun 17, 2019 at 8:59 PM Terry Bowling wrote:
>
> Oh, I forgot to add that related to parallel installations, when conflicting
> modules are desired, generally containerization or virtualization is the
> recommended solution. However, this is from the RHEL user persona
> perspective. W
On Mon, Jun 17, 2019, at 2:51 PM, Neal Gompa wrote:
> RPM-OSTree is functionally irrelevant in this discussion,
Changing how we handle the kernel is certainly relevant.
> since it has
> its own behavior patterns and eschews compatibility with the greater
> ecosystem anyway.
I don't think th
Oh, I forgot to add that related to parallel installations, when
conflicting modules are desired, generally containerization or
virtualization is the recommended solution. However, this is from the RHEL
user persona perspective. We realize that is a very different user persona
from say a develope
Regarding to a few of the questions about why modularity was created in the
first place (paraphrased), I can offer the following background. Note, I
was not on the team at the very beginning but have been very involved for
the last ~2 years.
Do not consider the following to be formal answers, gui
On Mon, Jun 17, 2019 at 2:29 PM Colin Walters wrote:
>
> On Mon, Jun 17, 2019, at 4:47 AM, Michael Schroeder wrote:
> > On Fri, Jun 14, 2019 at 12:12:01PM -0400, Neal Gompa wrote:
> > > I would actually really like to see rpm's multiversioning capabilities
> > > extended to support this.
> >
> > I
On 6/14/19 6:29 AM, Daniel Mach wrote:
Dne 14. 06. 19 v 6:23 Samuel Sieb napsal(a):
After reading the bug report and the discussions, I still don't
understand why dnf is complaining about a conflict with packages
(modules?) that are not installed and are not even trying to be
installed. Can s
On Mon, Jun 17, 2019, at 4:47 AM, Michael Schroeder wrote:
> On Fri, Jun 14, 2019 at 12:12:01PM -0400, Neal Gompa wrote:
> > I would actually really like to see rpm's multiversioning capabilities
> > extended to support this.
>
> I'd actually prefer to drop the multiversion mode for the kernel a
On Sun, Jun 16, 2019 at 2:53 AM Remi Collet wrote:
>
> Le 14/06/2019 à 20:03, Josh Boyer a écrit :
> > On Fri, Jun 14, 2019 at 3:50 AM Remi Collet
> > wrote:
> >>
> >>
> >>> IMHO, having library in modules is an error, this can only raise issues
> >>
> >> Some examples, taken from RHEL-8
> >>
>
On Mon, Jun 17, 2019 at 5:35 AM Michael Schroeder wrote:
>
> On Fri, Jun 14, 2019 at 12:12:01PM -0400, Neal Gompa wrote:
> > I would actually really like to see rpm's multiversioning capabilities
> > extended to support this.
>
> I'd actually prefer to drop the multiversion mode for the kernel and
On Mon, Jun 17, 2019 at 5:35 AM Michael Schroeder wrote:
>
> On Fri, Jun 14, 2019 at 12:12:01PM -0400, Neal Gompa wrote:
> > I would actually really like to see rpm's multiversioning capabilities
> > extended to support this.
>
> I'd actually prefer to drop the multiversion mode for the kernel and
On Fri, Jun 14, 2019 at 12:12:01PM -0400, Neal Gompa wrote:
> I would actually really like to see rpm's multiversioning capabilities
> extended to support this.
I'd actually prefer to drop the multiversion mode for the kernel and
instead add the version to the kernel package name.
Cheers,
Micha
On 14. 06. 19 6:27, Carl George wrote:
I think the best option is to create non-modular compat packages. In my
opinion, modularity makes sense for end user applications, but I'm not sure
what benefits it has for libraries. Libraries tend to work well as compat
packages, so I implemented this
On Sun, Jun 16, 2019 at 7:15 AM Kevin Kofler wrote:
>
> Adam Samalik wrote:
> > So, I'd like to discuss the libgit issue [1] [2] we're experiencing. With
> > a help of a few people, I've put together this post to get us on common
> > ground: https://commun
Adam Samalik wrote:
> So, I'd like to discuss the libgit issue [1] [2] we're experiencing. With
> a help of a few people, I've put together this post to get us on common
> ground: https://communityblog.fedoraproject.org/modularity-vs-libgit/
>
> There are few ideas
Le 14/06/2019 à 20:03, Josh Boyer a écrit :
> On Fri, Jun 14, 2019 at 3:50 AM Remi Collet wrote:
>>
>>
>>> IMHO, having library in modules is an error, this can only raise issues
>>
>> Some examples, taken from RHEL-8
>>
>> libJudy is part of the mariadb module ... (without -devel)
>> libssh2 is p
On Fri, Jun 14, 2019 at 3:50 AM Remi Collet wrote:
>
>
> > IMHO, having library in modules is an error, this can only raise issues
>
> Some examples, taken from RHEL-8
>
> libJudy is part of the mariadb module ... (without -devel)
> libssh2 is part of the virt module... (without -devel)
> libzip i
> We could go a step further and extend rpm and dnf to support multiple
> versions of same named packages for installation. This is doable but
> not necessarily trivial.
Having rescued this week a system in abysmal stale, with traces of rpm
forcing right and left, I'd say this would also requir
> > Thanks to soname, library are perfect use case for parallel installation
> > of multiple versions.
>
> +1
>
> We could go a step further and extend rpm and dnf to support multiple
> versions of same named packages for installation. This is doable but
Both rpm and dnf can do that, try running
> Or you think changing huge pieces of infrastructure, and working for
> 3+ years on a project (modularity) was done just to have 3 versions of
> Node.js available?
Of course not. Modularity is a great fit to provide multiple versions many
applications (in one repository), such as php, mariadb,
I've put together this post to get us on common
> >> ground: https://communityblog.fedoraproject.org/modularity-vs-libgit/
> >>
> >> There are few ideas about solving the issue right now. But we might be able
> >> to think about better ways to deal with similar
I did not intend to provide solution to the problem, just as an idea.
Or you think changing huge pieces of infrastructure, and working for
3+ years on a project (modularity) was done just to have 3 versions of
Node.js available?
On Fri, Jun 14, 2019 at 4:36 PM Carl George wrote:
>
> > So what is
I've put together this post to get us on common
> >> ground: https://communityblog.fedoraproject.org/modularity-vs-libgit/
> >>
> >> There are few ideas about solving the issue right now. But we might be able
> >> to think about better ways to deal with simi
ps://communityblog.fedoraproject.org/modularity-vs-libgit/
>>
>> There are few ideas about solving the issue right now. But we might be able
>> to think about better ways to deal with similar issues long-term. Let's do
>> this!
>
> IMHO, having library in modules is an
> So what is the point of modules then? If we want just multiple
> versions of a few applications, we can just have few repositories.
Add another repository for every alternate version (stream) doesn't scale.
___
devel mailing list -- devel@lists.fedorap
Dne 14. 06. 19 v 6:23 Samuel Sieb napsal(a):
After reading the bug report and the discussions, I still don't
understand why dnf is complaining about a conflict with packages
(modules?) that are not installed and are not even trying to be
installed. Can someone explain that?
The dependency re
> Modules are fine for applications.
So what is the point of modules then? If we want just multiple
versions of a few applications, we can just have few repositories.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
et us on common
> > ground: https://communityblog.fedoraproject.org/modularity-vs-libgit/
> >
> > There are few ideas about solving the issue right now. But we might be
> able
> > to think about better ways to deal with similar issues long-term. Let's
> do
> > this!
>
> IMHO, havi
et us on
> common
> ground: https://communityblog.fedoraproject.org/modularity-vs-libgit/
>
> There are few ideas about solving the issue right now. But we might be
> able to think about better ways to deal with similar issues long-term.
> Let's do this!
>
> [1] https://
> IMHO, having library in modules is an error, this can only raise issues
Some examples, taken from RHEL-8
libJudy is part of the mariadb module ... (without -devel)
libssh2 is part of the virt module... (without -devel)
libzip is part of the php module...
etc
How are we going to manage this in
Le 13/06/2019 à 20:31, Adam Samalik a écrit :
> So, I'd like to discuss the libgit issue [1] [2] we're experiencing. With a
> help of a few people, I've put together this post to get us on common
> ground: https://communityblog.fedoraproject.org/modularity-vs-libgit/
>
I think the best option is to create non-modular compat packages. In my
opinion, modularity makes sense for end user applications, but I'm not sure
what benefits it has for libraries. Libraries tend to work well as compat
packages, so I implemented this in copr to try it out.
* https://copr.f
After reading the bug report and the discussions, I still don't
understand why dnf is complaining about a conflict with packages
(modules?) that are not installed and are not even trying to be
installed. Can someone explain that?
___
devel mailing li
at 9:22 PM Adam Samalik wrote:
>
> So, I'd like to discuss the libgit issue [1] [2] we're experiencing. With a
> help of a few people, I've put together this post to get us on common ground:
> https://communityblog.fedoraproject.org/modularity-vs-libgit/
>
>
So, I'd like to discuss the libgit issue [1] [2] we're experiencing. With a
help of a few people, I've put together this post to get us on common
ground: https://communityblog.fedoraproject.org/modularity-vs-libgit/
There are few ideas about solving the issue right now. But we m
49 matches
Mail list logo
