On 2019-11-20, John M. Harris Jr wrote:
> On Tuesday, November 19, 2019 3:52:27 AM MST Petr Pisar wrote:
>> If you start fidling with things in PATH, you have the problem of SCL. And
>> as you wrote, SCL is terrible. And that was the reason why we have
>> modularity: We do not want to relocate
On Tuesday, November 19, 2019 9:20:29 AM MST Kevin Kofler wrote:
> But the scripts do not need to care about the version of Perl you are
> running, do they? It matters for compiled code, but why for Perl scripts?
> Those can just run with the default version of Perl if they support it, or
>
On Tuesday, November 19, 2019 3:52:27 AM MST Petr Pisar wrote:
> If you start fidling with things in PATH, you have the problem of SCL. And
> as you wrote, SCL is terrible. And that was the reason why we have
> modularity: We do not want to relocate code to non-standard paths.
I may be a bit
Petr Pisar wrote:
> That's nice theory that will never come true becaue it would require to
> make all Perl code parallel-installable. And Perl code is not only
> libraries as in the Python language. That's also myriad of Perl scripts
> that you want to have in PATH.
But the scripts do not need
On 2019-11-19, Igor Gnatenko wrote:
> Yes, but what you have described is basically to create 2 streams of
> perl-Sys-Virt module. Which is probably not what normal people want.
Having two different perl-Sys-Virt packages was requesed by
Daniel. That was not my choice.
> Creating module for one
Yes, but what you have described is basically to create 2 streams of
perl-Sys-Virt module. Which is probably not what normal people want.
Creating module for one package is the worst idea ever.
Sure, bundling perl-Sys-Virt into the libvirt module would solve the
problem, but then what's the point
On 2019-11-16, Kevin Kofler wrote:
> Petr Pisar wrote:
>> With your proposal Bugzilla packager would have to package Bugzilla
>> twice: as a normal package for default Perl 5.26 and as a module for Perl
>> 5.30. Then a user would have hard time to select the right combinations of
>> Perl and
On 2019-11-15, Igor Gnatenko wrote:
> On Fri, Nov 15, 2019, 17:38 Petr Pisar wrote:
>> On 2019-11-15, Daniel P Berrang=C3=A9 wrote:
>> >
>> > Consider if we move the virtualization stack (QEMU & Libvirt) into a
>> > module with two streams, one libvirt 5.8.0 and one libvirt 6.1.0.
>> >
>> >
On 2019-11-15, Przemek Klosowski via devel
wrote:
> Of course in practice the combinatorial behavior only happens within the
> subsets of software that depend on each other, but, nevertheless, it
> seems to me that this means that we have to control and limit the number
> of interdependent
Le samedi 16 novembre 2019 à 19:05 +0100, clime a écrit :
> On Sat, 16 Nov 2019 at 18:54, Nicolas Mailhot via devel
> wrote:
> > Le samedi 16 novembre 2019 à 18:42 +0100, clime a écrit :
> > > On Sat, 16 Nov 2019 at 08:38, Nicolas Mailhot via devel
> > > wrote:
> > > > Le samedi 16 novembre 2019
On Sat, 16 Nov 2019 at 18:54, Nicolas Mailhot via devel
wrote:
>
> Le samedi 16 novembre 2019 à 18:42 +0100, clime a écrit :
> > On Sat, 16 Nov 2019 at 08:38, Nicolas Mailhot via devel
> > wrote:
> > > Le samedi 16 novembre 2019 à 03:38 +0100, clime a écrit :
> > > > > A true solution would be
Le samedi 16 novembre 2019 à 18:42 +0100, clime a écrit :
> On Sat, 16 Nov 2019 at 08:38, Nicolas Mailhot via devel
> wrote:
> > Le samedi 16 novembre 2019 à 03:38 +0100, clime a écrit :
> > > > A true solution would be blending modularity into RPM.
> > > > At build time as well as at
On Sat, 16 Nov 2019 at 08:38, Nicolas Mailhot via devel
wrote:
>
> Le samedi 16 novembre 2019 à 03:38 +0100, clime a écrit :
> > > A true solution would be blending modularity into RPM.
> > > At build time as well as at installation time.
> >
> > I agree this would be the best. Basically, final
>
Le samedi 16 novembre 2019 à 09:35 +0100, Lukas Ruzicka a écrit :
>
>
> > Either the strategy should be:
> >
> > "We offer alternate Perl versions for containers etc. they conflict
> > with the
> > default Perl version and with the non-modular apps. That is known
> > and accepted."
That won't
Either the strategy should be:
>
> "We offer alternate Perl versions for containers etc. they conflict with
> the
> default Perl version and with the non-modular apps. That is known and
> accepted."
>
> Or the strategy should be:
>
> "We build all our Perl applications for all our Perl versions,
Le samedi 16 novembre 2019 à 08:37 +0100, Nicolas Mailhot a écrit :
>
> Sure, do some rpm fixing if necessary so the result feels less like a
> kludge than %dist. But, don’t rely on an external framework to do
> things for you instead of doing the necessary work (if any) at the
> component format
Le samedi 16 novembre 2019 à 03:38 +0100, clime a écrit :
> > A true solution would be blending modularity into RPM.
> > At build time as well as at installation time.
>
> I agree this would be the best. Basically, final
> product of a module build should be an rpm. modulemd
> file should be kind
> A true solution would be blending modularity into RPM.
> At build time as well as at installation time.
I agree this would be the best. Basically, final
product of a module build should be an rpm. modulemd
file should be kind of a meta-spec file which can be built
distributively and that
Petr Pisar wrote:
> With your proposal Bugzilla packager would have to package Bugzilla
> twice: as a normal package for default Perl 5.26 and as a module for Perl
> 5.30. Then a user would have hard time to select the right combinations of
> Perl and Bugzilla. It would double fork work pacakgers
Przemek Klosowski via devel wrote:
> so for one module with two versions, we will have 2 builds, for 2
> modules with two versions we'll have four builds, and in general for N
> modules with M versions on average, we will have N^M builds?
M^N actually.
1 module with M versions = M builds
2
On 15. 11. 19 19:10, Petr Pisar wrote:
Now you can think another modularity fatatic who wants to modularize
everything and have all modules in multiple versions. Not at all.
Don't worry, I don't consider anybody a modular fanatic. Yet anyway.
Thanks for you answer, it has been valuable to me
On 2019-11-15, Miro Hrončok wrote:
> On 15. 11. 19 16:11, Petr Pisar wrote:
>> On 2019-11-15, Miro Hrončok wrote:
>>> On 15. 11. 19 14:32, Petr Pisar wrote:
On 2019-10-04, Miro Hrončok wrote:
> Wouldn't it be easier if the "default stream" would just behave like
> a regular
On 11/15/19 11:27 AM, Petr Pisar wrote:
No. Modularity solves this combination problem with "stream expansion".
Sources for such module exists only once, you submit them for building
with fedpkg only once, but a build systems computes all combinations
(this the stream expansion) and schedules a
On Fri, Nov 15, 2019, 17:38 Petr Pisar wrote:
> On 2019-11-15, Daniel P Berrangé wrote:
> > On Fri, Nov 15, 2019 at 02:53:08PM -, Petr Pisar wrote:
> >> On 2019-11-15, John M. Harris Jr wrote:
> >> > On Friday, November 15, 2019 6:32:21 AM MST Petr Pisar wrote:
> >> >> Example: I have
On 2019-11-15, Daniel P Berrangé wrote:
> On Fri, Nov 15, 2019 at 02:53:08PM -, Petr Pisar wrote:
>> On 2019-11-15, John M. Harris Jr wrote:
>> > On Friday, November 15, 2019 6:32:21 AM MST Petr Pisar wrote:
>> >> Example: I have Perl 5.26 as a default version. I have Perl 5.30 as an
>> >>
On Friday, November 15, 2019 7:53:08 AM MST Petr Pisar wrote:
> Modularity can achieve it when both Perls are packaged as a module. I'm
> only showing why we need default stream if we want modules.
If that's the case, why not build a (separate) Modularity distro? If
Modularity cannot work with
On 15. 11. 19 16:11, Petr Pisar wrote:
On 2019-11-15, Miro Hrončok wrote:
On 15. 11. 19 14:32, Petr Pisar wrote:
On 2019-10-04, Miro Hrončok wrote:
Wouldn't it be easier if the "default stream" would just behave like
a regular package?
I can think of two solutions of that:
1. (drastic for
On Fri, Nov 15, 2019 at 02:53:08PM -, Petr Pisar wrote:
> On 2019-11-15, John M. Harris Jr wrote:
> > On Friday, November 15, 2019 6:32:21 AM MST Petr Pisar wrote:
> >> Example: I have Perl 5.26 as a default version. I have Perl 5.30 as an
> >> laternative version. Now I want to package
On 2019-11-15, Miro Hrončok wrote:
> On 15. 11. 19 14:32, Petr Pisar wrote:
>> On 2019-10-04, Miro Hrončok wrote:
>>> Wouldn't it be easier if the "default stream" would just behave like
>>> a regular package?
>>>
>>> I can think of two solutions of that:
>>>
>>> 1. (drastic for modular
On 2019-11-15, John M. Harris Jr wrote:
> On Friday, November 15, 2019 6:32:21 AM MST Petr Pisar wrote:
>> Example: I have Perl 5.26 as a default version. I have Perl 5.30 as an
>> laternative version. Now I want to package Bugzilla that's written in
>> Perl. How do you package Bugzilla so that
On 15. 11. 19 14:32, Petr Pisar wrote:
On 2019-10-04, Miro Hrončok wrote:
Wouldn't it be easier if the "default stream" would just behave like
a regular package?
I can think of two solutions of that:
1. (drastic for modular maintainers)
We keep miantaining the default versions of things as
On 2019-10-07, Jaroslav Mracek wrote:
> I would like to open discussions more widely, because we are talking about
> future of software distribution and discussing only particular issue is not
> an approach how to delivery solid and stable architecture.
>
> What issues I have in mind?
> 1. Fedora
On Friday, November 15, 2019 6:32:21 AM MST Petr Pisar wrote:
> Example: I have Perl 5.26 as a default version. I have Perl 5.30 as an
> laternative version. Now I want to package Bugzilla that's written in
> Perl. How do you package Bugzilla so that it works with Perl 5.26 as
> well as with Perl
On 2019-10-04, Miro Hrončok wrote:
> Wouldn't it be easier if the "default stream" would just behave like
> a regular package?
>
> I can think of two solutions of that:
>
> 1. (drastic for modular maintainers)
>
> We keep miantaining the default versions of things as ursine packages.
> We only
On Thu, Oct 24, 2019 at 12:42:27PM +0200, Kevin Kofler wrote:
> Neal Gompa wrote:
>
> > On Thu, Oct 24, 2019 at 4:31 AM Lukas Ruzicka wrote:
> >> I believe, that if modularity was opt-in, we would be able to use it just
> >> fine, as it is designed now with some little tweakings, such as DNF
>
Neal Gompa wrote:
> On Thu, Oct 24, 2019 at 4:31 AM Lukas Ruzicka wrote:
>> I believe, that if modularity was opt-in, we would be able to use it just
>> fine, as it is designed now with some little tweakings, such as DNF
>> providing enough info on retired or discontinued streams, offering a
>>
On Thu, Oct 24, 2019 at 4:31 AM Lukas Ruzicka wrote:
>
> As far as tooling is concerned, I have been seeing complaints about DNF doing
> a bad job, but from the perspective of acceptance
> testing, it's the DNF operations that usually work fine with installing,
> enabling, disabling, removing,
This is a policy choice, not a technical matter. If modules became more
> popular, and the dependencies between modules grew, we'd need
> to settle on similar rules, where bigger changes are done with a certain
> cadence. This is why I think that the "independent lifecycles for modules"
> are
On Wed, Oct 23, 2019 at 12:56:41PM -0400, Matthew Miller wrote:
> However, I also have a pretty strong bias towards people who showed up to
> do the work, and the decisions they've made. That doesn't mean we're stuck
> and can't adjust -- in fact, adjusting as we've gone along is a lot of why
>
On Sun, Oct 20, 2019 at 10:47:15AM +, Zbigniew Jędrzejewski-Szmek wrote:
> In general, yes. If the package versions have incompatibilities and/or
> user-visible changes, a different stream is needed for each Fedora
> release. There was a subthread about this recently, starting at
In this
On Sun, Oct 20, 2019 at 09:07:27AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > Because this keeps coming up, we talked about this at the Fedora Council
> > meeting today. Our goals for modularity are:
> > 2. Those alternate streams should be able to have different lifecycles.
>
> Hmm, it
On Mon, 21 Oct 2019 at 11:08, Randy Barlow wrote:
>
> On Mon, 2019-10-21 at 09:16 -0400, Stephen John Smoogen wrote:
> > The problem is that COPRs do not have any way of communicating with
> > each other. If I grab from copr-A and it has libfoo-2.3.1-1 and I
> > grab
> > from copr-B and it has
On Mon, 2019-10-21 at 14:00 +, Zbigniew Jędrzejewski-Szmek wrote:
> Packaging in Fedora is
> definitely harder than it used to be. We still haven't really
> recovered from
> pkgdb retirement, various infra tools don't have enough support, etc.
> No easy solutions to this problem either, but I
On Mon, 21 Oct 2019 at 09:37, Fabio Valentini wrote:
>
> On Mon, Oct 21, 2019, 15:17 Stephen John Smoogen wrote:
>>
>> On Mon, 21 Oct 2019 at 01:55, Zbigniew Jędrzejewski-Szmek
>> wrote:
>> >
>> > On Sun, Oct 20, 2019 at 09:30:52PM -0400, Stephen John Smoogen wrote:
>> > > If I were to start
On Mon, 2019-10-21 at 14:00 +, Zbigniew Jędrzejewski-Szmek wrote:
> The problem is hard. If there was an obvious solution, we wouldn't be
> having this discussion.
I've pointed out a few times that other distros have solved the "too
fast, too slow" problem. In at least one case, as long ago
On Mon, 2019-10-21 at 09:16 -0400, Stephen John Smoogen wrote:
> The problem is that COPRs do not have any way of communicating with
> each other. If I grab from copr-A and it has libfoo-2.3.1-1 and I
> grab
> from copr-B and it has libfoo-2.3.2-2 then I am going to replace
> copr-A's packages
On 10/21/19 7:16 AM, Stephen John Smoogen wrote:
On Mon, 21 Oct 2019 at 01:55, Zbigniew Jędrzejewski-Szmek
wrote:
On Sun, Oct 20, 2019 at 09:30:52PM -0400, Stephen John Smoogen wrote:
If I were to start from scratch on this, I would look at the simplest
solution I would want from Boltron. I
On Mon, Oct 21, 2019 at 03:36:53PM +0200, Fabio Valentini wrote:
> On Mon, Oct 21, 2019, 15:17 Stephen John Smoogen wrote:
>
> > On Mon, 21 Oct 2019 at 01:55, Zbigniew Jędrzejewski-Szmek
> > wrote:
> > >
> > > On Sun, Oct 20, 2019 at 09:30:52PM -0400, Stephen John Smoogen wrote:
> > > > If I
On Mon, Oct 21, 2019, 15:17 Stephen John Smoogen wrote:
> On Mon, 21 Oct 2019 at 01:55, Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Sun, Oct 20, 2019 at 09:30:52PM -0400, Stephen John Smoogen wrote:
> > > If I were to start from scratch on this, I would look at the simplest
> > > solution I
On Mon, 21 Oct 2019 at 01:55, Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Sun, Oct 20, 2019 at 09:30:52PM -0400, Stephen John Smoogen wrote:
> > If I were to start from scratch on this, I would look at the simplest
> > solution I would want from Boltron. I want to make it so a package team can
> >
>
>
>
> This has been working quite fine so far, so it would be bad to loose this
> capability, as the actual
> users in question are definitely not power users and will not be able to
> fix any of these issues
> by themselves.
>
>
+1, this was one of my points, too. I think that Fedora should be
On Fri, 2019-10-18 at 13:05 +0200, Lukas Ruzicka wrote:
>
> > Or, even better (or worse): Sombody installs GIMP via GNOME Software,
> >
> > and under the hood, dnf does its magic and installs gimp from the
> >
> > module, which might depend on another, even non-default module, etc.
> >
> > But
On Thursday, October 17, 2019 4:28:27 PM MST Kevin Kofler wrote:
> Adam Williamson wrote:
>
> > Of course if you just don't modularize FreeIPA at all you don't have
> > the kickstart problem, but then you *do* still have the 'we're stuck
> > shipping this one version of FreeIPA for the next
Dne 18. 10. 19 v 17:04 Matthew Miller napsal(a):
> On Fri, Oct 18, 2019 at 01:03:24PM +0200, Lukas Ruzicka wrote:
>> Exactly ... this is what I believe, too. I think that Fedora users put
>> Fedora on their desktops and laptops to be creative in many ways of
>> creativity. Some make make music,
On Sun, Oct 20, 2019 at 09:30:52PM -0400, Stephen John Smoogen wrote:
> If I were to start from scratch on this, I would look at the simplest
> solution I would want from Boltron. I want to make it so a package team can
> make a set of packages in a repository and work out how I can interact with
On Sun, Oct 20, 2019 at 15:20 Zbigniew Jędrzejewski-Szmek
wrote:
> On Tue, Oct 15, 2019 at 09:26:31PM -0400, Stephen Gallagher wrote:
> > Alternate Proposal:
> >
> > Most things from the original proposal in the first message of this
> > thread remains the same except:
> >
> > Module stream
On Tue, Oct 15, 2019 at 09:26:31PM -0400, Stephen Gallagher wrote:
> Alternate Proposal:
>
> Most things from the original proposal in the first message of this
> thread remains the same except:
>
> Module stream metadata would gain two new optional attributes,
> "upgrades:" and "obsoletes:".
On 15. 10. 19 19:25, Miro Hrončok wrote:
On 15. 10. 19 19:13, Kevin Fenzi wrote:
So, I see the following modules (in rawhide anyhow) that don't seem to
have non modular versions:
avocado
cri-o
django
dwm
eclipse
gimp
jmc
lizardfs
mysql
ninja
perl-bootstrap
stratis
Do all of those have
On Sun, Oct 20, 2019 at 10:47:15AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, Oct 20, 2019 at 11:35:37AM +0200, Fabio Valentini wrote:
> > On Sun, Oct 20, 2019 at 11:09 AM Zbigniew Jędrzejewski-Szmek
> > wrote:
> > >
> > > On Wed, Oct 16, 2019 at 02:48:13PM -0400, Matthew Miller wrote:
>
On Sun, Oct 20, 2019 at 11:35:37AM +0200, Fabio Valentini wrote:
> On Sun, Oct 20, 2019 at 11:09 AM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > On Wed, Oct 16, 2019 at 02:48:13PM -0400, Matthew Miller wrote:
> > > On Wed, Oct 16, 2019 at 08:31:10AM -0400, Stephen Gallagher wrote:
> > > > This is
On pe, 18 loka 2019, Martin Kolman wrote:
On Fri, 2019-10-18 at 11:39 +0300, Alexander Bokovoy wrote:
On to, 17 loka 2019, Orion Poplawski wrote:
> > > You could install the ipa-client package and enroll a system into IPA
from a
> > > kickstart in RHEL 7 too.. Without modules. That's what I've
On Sun, Oct 20, 2019 at 11:09 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Wed, Oct 16, 2019 at 02:48:13PM -0400, Matthew Miller wrote:
> > On Wed, Oct 16, 2019 at 08:31:10AM -0400, Stephen Gallagher wrote:
> > > This is not true. It should be *possible* to have a fully modularized
> > >
On Wed, Oct 16, 2019 at 02:48:13PM -0400, Matthew Miller wrote:
> On Wed, Oct 16, 2019 at 08:31:10AM -0400, Stephen Gallagher wrote:
> > This is not true. It should be *possible* to have a fully modularized
> > distribution, but that isn't a specific goal for Fedora or RHEL.
>
> Because this keeps
On Fri, Oct 18, 2019 at 10:42:54AM -0700, Howard Howell wrote:
> I just got a new computer, an Intel with Nvidia 2060 graphics card. I
> could NOT get fedora to install or boot. For the first time since
Do you recall any specifics? This is very unlikely to be related to
modularity or anything
On Fri, 2019-10-18 at 13:05 +0200, Lukas Ruzicka wrote:
>
> > Or, even better (or worse): Sombody installs GIMP via GNOME
> > Software,
> >
> > and under the hood, dnf does its magic and installs gimp from the
> >
> > module, which might depend on another, even non-default module,
> > etc.
> >
On Fri, Oct 18, 2019 at 01:03:24PM +0200, Lukas Ruzicka wrote:
> Exactly ... this is what I believe, too. I think that Fedora users put
> Fedora on their desktops and laptops to be creative in many ways of
> creativity. Some make make music, some enhance pictures, some model in
> Blender, cut
On Thu, 2019-10-17 at 14:44 -0600, Orion Poplawski wrote:
> On 10/17/19 2:35 PM, Adam Williamson wrote:
> > On Thu, 2019-10-17 at 09:32 -0700, John M. Harris Jr wrote:
> > > On Thursday, October 17, 2019 1:59:19 AM MST Alexander Bokovoy wrote:
> > > > The one thing we are using default modular
On Fri, 2019-10-18 at 11:39 +0300, Alexander Bokovoy wrote:
> On to, 17 loka 2019, Orion Poplawski wrote:
> > > > You could install the ipa-client package and enroll a system into IPA
> > > > from a
> > > > kickstart in RHEL 7 too.. Without modules. That's what I've deployed
> > > > for the
> >
17.10.2019, 17:15, "Stephen John Smoogen" :
> On Wed, 16 Oct 2019 at 20:27, Stephen Gallagher wrote:
>>
>
>> So, literally every word of this is wrong. The negative feedback is
>> not "overwhelming". It is approximately four noisy individuals, all of
>> whom have expressed zero interest in
This does not work for server components and is not generalizable. For
> example, you cannot have multiple versions of Samba running on the same
> system. You cannot have multiple versions of FreeIPA running on the same
> system either. These server components have requirements beyond package
>
On Thu, 2019-10-17 at 09:47 -0400, Stephen Gallagher wrote:
> On Wed, Oct 16, 2019 at 9:39 PM Kevin Kofler wrote:
> > So it looks like I did not describe clearly enough what my proposed
> > enable_modules=0 flag would do. ("Disable all module code" was apparently
> > too vague.)
> >
> > How I
Or, even better (or worse): Sombody installs GIMP via GNOME Software,
> and under the hood, dnf does its magic and installs gimp from the
> module, which might depend on another, even non-default module, etc.
> But then, what will happen when that module is EOL, and the user has
> never even
>
>
> I'm comfortable saying that most Fedora users are not installing the
> distro
> just to support one specific application, as one might with RHEL or
> CentOS,
> but to benefit from the Four Foundations of Fedora, in this case the most
> important ones being Freedom, Features and First.
>
On pe, 18 loka 2019, Kevin Kofler wrote:
Alexander Bokovoy wrote:
That's my point -- requiring parallel installability is not really a
MUST, especially in my area. You are driving this requirement as if
nothing else could solve your issues.
I am not. This is a strawman.
What I am saying is
Alexander Bokovoy wrote:
> That's my point -- requiring parallel installability is not really a
> MUST, especially in my area. You are driving this requirement as if
> nothing else could solve your issues.
I am not. This is a strawman.
What I am saying is that modules on which other modules have
On to, 17 loka 2019, Orion Poplawski wrote:
You could install the ipa-client package and enroll a system into IPA from a
kickstart in RHEL 7 too.. Without modules. That's what I've deployed for the
environments I support, for example. Using a module is not required there.
That wasn't the
On pe, 18 loka 2019, Kevin Kofler wrote:
Alexander Bokovoy wrote:
This does not work for server components and is not generalizable. For
example, you cannot have multiple versions of Samba running on the same
system. You cannot have multiple versions of FreeIPA running on the same
system
Adam Williamson wrote:
> Of course if you just don't modularize FreeIPA at all you don't have
> the kickstart problem, but then you *do* still have the 'we're stuck
> shipping this one version of FreeIPA for the next seventy jillion
> years' problem.
That is purely a RHEL thing though. I do not
Stephen Gallagher wrote:
> I think that's a little harsh (but probably fair given my tone above).
> Can we agree that we're both on the same side: we want Fedora to be
> excellent?
I accept your apologies for your harsh tone (and I appreciate your much more
constructive reply this time, thank
Przemek Klosowski via devel wrote:
> 3. modularity allows choosing non-default versions, which is great for
> a particular application, but conflicts with other apps, forcing us
> to choose only one of them. This provides a working solution for at
> least some people, so it's useful
Alexander Bokovoy wrote:
> This does not work for server components and is not generalizable. For
> example, you cannot have multiple versions of Samba running on the same
> system. You cannot have multiple versions of FreeIPA running on the same
> system either. These server components have
On Thu, 2019-10-17 at 14:44 -0600, Orion Poplawski wrote:
> On 10/17/19 2:35 PM, Adam Williamson wrote:
> > On Thu, 2019-10-17 at 09:32 -0700, John M. Harris Jr wrote:
> > > On Thursday, October 17, 2019 1:59:19 AM MST Alexander Bokovoy wrote:
> > > > The one thing we are using default modular
On 10/17/19 2:35 PM, Adam Williamson wrote:
> On Thu, 2019-10-17 at 09:32 -0700, John M. Harris Jr wrote:
>> On Thursday, October 17, 2019 1:59:19 AM MST Alexander Bokovoy wrote:
>>> The one thing we are using default modular stream in RHEL 8 for is to be
>>> able to provide access to packages in
On Thu, 2019-10-17 at 09:32 -0700, John M. Harris Jr wrote:
> On Thursday, October 17, 2019 1:59:19 AM MST Alexander Bokovoy wrote:
> > The one thing we are using default modular stream in RHEL 8 for is to be
> > able to provide access to packages in kickstart that were moved to
> > modules in
On to, 17 loka 2019, Kevin Kofler wrote:
Dependencies aren't arbitrary; if they were, there would be probably no
need to waste our time in working on the whole build part. Whether that
is useful to you or other subset of Fedora maintainers is not
guaranteed. However, using modular streams allows
On 10/17/19 12:27 PM, Stephen John Smoogen wrote:
people are going to add things into their modules to make whatever
software they need. If I find that I need libfoo2-2.34 in libreoffice
and you need libfoo2-2.40 in evolution.. then only one of the two
modules can be installed.You can either
Alexander Bokovoy wrote:
> On to, 17 loka 2019, Kevin Kofler wrote:
>>Building against the distribution's version of libraries instead of some
>>arbitrarily picked version is pretty much the whole point of non-modular
>>packages.
> Right, and building against carefully chosen collection of
On Thu, 2019-10-17 at 13:43 +0200, Miro Hrončok wrote:
> On 17. 10. 19 13:38, Alexander Bokovoy wrote:
> > Had there be default module streams for Java packages in buildroot, we
> > would have no problem.
>
> Had there been no default modular streams but regular packages instead, we
> would
>
On Thursday, October 17, 2019 1:59:19 AM MST Alexander Bokovoy wrote:
> The one thing we are using default modular stream in RHEL 8 for is to be
> able to provide access to packages in kickstart that were moved to
> modules in RHEL 8. An example is idm:client stream which is a default
> module
On Thu, 17 Oct 2019 at 10:06, Przemek Klosowski via devel
wrote:
>
> On 10/16/19 7:36 PM, Kevin Kofler wrote:
>
> It was never designed to solve parallel installability problem.
>
> … which is exactly why it causes version hell.
>
> Could you expand on that? Since a modular system currently
On Wed, 16 Oct 2019 at 20:27, Stephen Gallagher wrote:
>
> So, literally every word of this is wrong. The negative feedback is
> not "overwhelming". It is approximately four noisy individuals, all of
> whom have expressed zero interest in understanding the actual
> situation that they are trying
On Thu, Oct 17, 2019 at 10:17 AM Pierre-Yves Chibon wrote:
>
> On Thu, Oct 17, 2019 at 03:38:39AM +0200, Kevin Kofler wrote:
> > So bringing yourselves up now as "the people who can dig us out of this
> > situation" feels to me feels like intentionally making a patient sick so you
> > can "cure"
On Thu, Oct 17, 2019 at 03:38:39AM +0200, Kevin Kofler wrote:
> > So, literally every word of this is wrong. The negative feedback is
> > not "overwhelming". It is approximately four noisy individuals, all of
> > whom have expressed zero interest in understanding the actual
> > situation that they
On 10/16/19 7:36 PM, Kevin Kofler wrote:
It was never designed to solve parallel installability problem.
… which is exactly why it causes version hell.
Could you expand on that? Since a modular system currently prevents
parallel version installation, it may provide suboptimal/obsolete
On Thu, 17 Oct 2019 at 09:24, Miro Hrončok wrote:
>
> On 17. 10. 19 15:17, Stephen Gallagher wrote:
> > On Thu, Oct 17, 2019 at 4:33 AM Miro Hrončok wrote:
> >>
> >> On 17. 10. 19 2:27, Stephen Gallagher wrote:
> >>> So, literally every word of this is wrong. The negative feedback is
> >>> not
On Wed, Oct 16, 2019 at 9:39 PM Kevin Kofler wrote:
>
> So it looks like I did not describe clearly enough what my proposed
> enable_modules=0 flag would do. ("Disable all module code" was apparently
> too vague.)
>
> How I think it should work would be:
> * For repositories, it completely
On 17. 10. 19 15:17, Stephen Gallagher wrote:
On Thu, Oct 17, 2019 at 4:33 AM Miro Hrončok wrote:
On 17. 10. 19 2:27, Stephen Gallagher wrote:
So, literally every word of this is wrong. The negative feedback is
not "overwhelming". It is approximately four noisy individuals, all of
whom have
On Thu, Oct 17, 2019 at 4:33 AM Miro Hrončok wrote:
>
> On 17. 10. 19 2:27, Stephen Gallagher wrote:
> > So, literally every word of this is wrong. The negative feedback is
> > not "overwhelming". It is approximately four noisy individuals, all of
> > whom have expressed zero interest in
On Wed, 16 Oct 2019 at 13:33, Stephen Gallagher wrote:
>
> On Wed, Oct 16, 2019 at 1:19 PM Przemek Klosowski via devel
> wrote:
> >
> > On 10/15/19 9:26 PM, Stephen Gallagher wrote:
> I'm saying that the policy should forbid the use of that feature
> except for an absolute emergency, requiring
On 17. 10. 19 13:38, Alexander Bokovoy wrote:
Had there be default module streams for Java packages in buildroot, we
would have no problem.
Had there been no default modular streams but regular packages instead, we would
have no problem either.
But to extend there a bit, that would also be
1 - 100 of 215 matches
Mail list logo
