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
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 <
>>
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 ...
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
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
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
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
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
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
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
n 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 few people, I've put together this post to get us on co
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.
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.
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
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
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,
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.
> >
> >
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
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
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
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
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,
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
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://communityblog.fedorap
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 about solving
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
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
> 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
> > 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,
t 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 issues long
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
t 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 issues long
log.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 error, this can only
> 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 --
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
> 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
> > 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, having library in module
> 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://bugzilla.redhat.com/show_
> 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
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/
>
> There are
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.
*
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
e 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 might be able
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 might be able
49 matches
Mail list logo
