; is the recommended upgrade method and the requirement of
> keeping the upgrade path without downgrades isn't there anymore. (This comes
> up
> in the semiannual discussion about upgrade tests.)
>
> But I don't see an unambiguous statement in the Packaging Guidelines
x27; is the recommended upgrade method and the
> requirement of
> keeping the upgrade path without downgrades isn't there anymore.
> (This comes up
> in the semiannual discussion about upgrade tests.)
>
> But I don't see an unambiguous statement in the Packaging Guid
Dne 21. 11. 22 v 10:00 Zbigniew Jędrzejewski-Szmek napsal(a):
So… has there been any change of the Guidelines on this and where is
the official policy documented?
AFAIK no. We stick to common sense. In good and bad meaning of that.
Miroslav
___
devel
Hi,
I was looking for a clear answer in the packaging docs to the question whether
package nevr must be always higher in later releases. I recall people saying
that
now 'distro-upgrade' is the recommended upgrade method and the requirement of
keeping the upgrade path without downgr
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 cod
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
> with
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 confu
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 to
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 Bugzi
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.
>> >
>> > Now
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 mod
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 bl
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 installation
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, so
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 contain
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 a
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 module
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 a
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 package?
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 b
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 Perl
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
>> >> l
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 no
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 Bugzil
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 maintaine
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 it
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 u
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 5
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 mod
he time back, we
> have to focus on improving things for the upcoming releases, hence "from F32
> onwards". I would even propose it from F31 onwards, but I do not think FESCo
> is willing to delay the F31 release long enough to implement the required
> demodularization up
rds. (It is unfortunate that these have not been
considered for the existing releases, but we cannot turn the time back, we
have to focus on improving things for the upcoming releases, hence "from F32
onwards". I would even propose it from F31 onwards, but I do not think FESC
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, r
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 illus
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
> we'
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 case,
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 soun
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 lib
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 t
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 fro
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 as
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 whic
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 w
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 wer
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
> > m
>
>
>
> 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 o
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 sevent
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, so
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 metad
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:".
I'
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 defau
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
> > > distribut
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 to
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 video
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 stre
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 un
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
> ins
back into the non-modular repository. Which in some cases they
> > > probably cannot do, because they have build-dependencies that are in
> > > conflict. This is a highly non-trivial process and it would need to be
> > > done individually for every single package. That's far more
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 intera
>
>
> 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.
>
Exac
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 th
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 point,
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 either.
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 se
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 you
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 fo
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 requir
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 stre
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 k
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 RHEL
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 have
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 dependen
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
> ha
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 stre
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 preven
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" t
y individuals". This is
> getting really ridiculous! Why am I even arguing with somebody who clearly
> does not want to listen?
>
> And you are the people who brought us into this situation to begin with.
> Default streams should never have been allowed without:
> 1. an upgrade
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
version
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 "o
tent and shoves
> > it back into the non-modular repository. Which in some cases they
> > probably cannot do, because they have build-dependencies that are in
> > conflict. This is a highly non-trivial process and it would need to be
> > done individually for every single pac
1 - 100 of 303 matches
Mail list logo
