Le mercredi 13 novembre 2019 à 00:19 +0200, Aleksandar Kurtakov a écrit : > > > On Wed, Nov 13, 2019 at 12:02 AM John M. Harris Jr < > johnmh@xxxxxxxxxxxxx> wrote: > > On Tuesday, November 12, 2019 9:02:07 AM MST Aleksandra Fedorova > > wrote: > > > Again, no one forces you or any other packager to use modularity > > > tooling right now. > > > > This is not actually the case. We have several major packages which > > are ONLY > > available as modules, for example. > > So people would prefer no packages at all over packages in modules? I > ask this as the traditional rpm way of doing is simply not working > and that's the reason why many of us (old time Java packagers) just > gave up, it's purely impossible to satisfy the needs of multiple > "major" packages with same set of dependencies. This is not Java > problem only for sure - look at Rust, Go, etc. Having spend a lot of time Go-side this past year, there is *no* way in which traditional rpm packaging limits us. Traditional rpm packaging has always permitted packaging as many component versions as was needed. It *does* require that an ecosystem that can not settle down on a single component version, actually tracks what version each build uses. It *does* require defining an upgrade path once multiple versions are allowed to exist. It *does* require that multiple versions, expected to exist simultaneously on the filesystem, use different file paths (and thus requires defining those paths to be sure they do not collide). All of those are inescapable consequences of multi-versionning and parallel install. The native Go component format (also, confusingly, named module) handles those 3 constrains and won't present any core difficulty in rpm packaging once it is finished upstream. Fedora modules are an horrifically complex way to pretend those basic three constrains do not exist, while actually implementing them (except in a broken non-working way, because the *pretence* is that the constrains do not exist). And, having spent a lot of time packaging Java software 20 years ago, I can tell you that the Java language is no different from Go. *However* the Java ecosystem has spent a lot of time and energy, refusing to ackowledge it needs to track component versions, refusing to ackowledge it needs to define upgrade paths, refusing to ackowledge it needs to define version-specific file paths. *That* is your core problem, not packaging tech (rpm, module, maven osgi, or anything else). The reason you’re attracted to modules is that on *short* deployment time windows, you can pretend the constrains do not exist, and just use whatever component version is available. That is why ignoring the constrains works dev-side – everything is ephemeral, nothing is supposed to survive long after a dev build., nothing is shared with other builds. And modules allowed you to get rid of the past, ie reduce the time window, for a short while. The reason the result fell over, in rpm, and in modules, is that on *long* distro-scale deployment time windows, you can *not* ignore those constrains. Anything you do in modules, containers, or whatever, without taking the long-term versioning constrains into account, will only work for a short period of time. Unicorns do not exist in real life. Regards, -- Nicolas Mailhot _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
