Hello Petr, > So, first, I'd like to thank you for taking the time to think > about this. It's certainly interesting and tries to solve similar > problems from a completely different angle. > > Your proposal focuses on distribution packages rather than on > independent applications. I'd argue it introduces even more > packaging complexity (all packages would need to be modified to > depend on specific "streams" of other packages) than grouping > unmodified packages into modules. But if you want to provide multiple major versions of one software officially, the additional complexity to handle availability of those different versions in an ecosystem will always be there. I don't think anything can be done about that :(. But I also doubt that modularity, as it is, has a cure for that. What happens if you install an rpm from a module for which the rest of the ecosystem is not prepared? Meaning that it is too new and other standard available rpms have it as an unqualified dependency? And what happens if you introduce a module for which the rest of the modules is not prepared? Containers is not an answer but an excuse. I think it is simply a fact that if you want to provide multiple versions of the same software for a single system, you need to put some work into more explicit Requires and BuildRequires when needed. It can be a coordinated process though that would include pull requests for packages that use the package for which a new stream is being introduced. Also, it depends if there is a demand to do that at all. What I tried to propose makes it possible in a simple manner but it doesn't mean it needs to be done. > I also worry that with such a > fine-grained parallel availability, there would be very few > possible combinations of packages that could be effectively > installed on a single system. Not to mention QA efforts. Again, this imho comes from the fact that we are trying to provide parallel availability in the first place. If we weren't, then there wouldn't be any additional complexity. Nevertheless, I don't see a problem in keeping the same "ground" as we keep now for each Fedora release, which is all compatible, while also providing something optional above that, which might be less compatible (hopefully it is not but might be). Even this has an added value for users given that they are able maintain the ground if they want to. In my proposal, maintaining the ground means using the implicit installs ($ sudo dnf install git) or explicit ones but only those that use the lowest available streams for a periodical Fedora release. For a periodical release, we can do it so that the lowest available streams are at the same time the lowest compatible ones and they hence form a good "ground" from which a user can optionally go up. We provide the ground already, in fact. But we don't provide something on top of that. > > -- > > That aside, a couple points touching some aspects of your proposal > that you might interesting: > > * DistTag isn't actually unused. The current modularity > implementation uses it to label MBS-procuded RPMs. The > tag is also used by other distributions and we're currently > introducing a new header to avoid the conflict. > https://pagure.io/modularity/issue/113 Well, some other tag than DistTag can be used for specifying the stream/branch name. I wanted to propose something that already exists but is unused at least in Fedora (non-modular). > > * Soon, users will be able to choose whether they follow the > defaults for each individual module or stay on the stream they > initially picked/enabled. > https://pagure.io/modularity/issue/108 > > * We do not compare stream names in any way, they're just strings. Yes, the ordering in my proposal is there to make installation user-friendly so that users don't need to specify explicit versions every time and at the same time so that it can be made clear what will be installed by default. I would like if a future/imagined interface of our update system made the ordering clear graphically for packagers to be able to navigate quickly. Of course, one can always also do: $ git branch | LC_ALL=en_US.UTF-8 sort locally to see how the branches sort. > Streams don't have to be just major versions of upstream > software, they can indeed be anything the packagers want them to > be -- experimental builds, builds with different compiler flags, > builds with or without specific dependencies, and so on. Yes, that's possible in my proposal too. I would argue that the main use of streams will be separating major versions from each other. Even minor ones can be separated if it is useful. Other uses that involve twiddling with compiler flags or deps are possible too given that the branch has a descriptive name. In this case, it would be good to put the stream name into Release: tag too so that users will see also from the rpm name that this is something extra. And also, there should be a standard stream that sorts lower, I would say. > Modules can build packages from the same sources in different > buildroots or with different macros easily to enable this. That's nice. The added value on top of my proposal, that I can see, is if you want to provide an application which is composed from multiple base packages where each base package is compiled specifically to be optimal for the given use-case. You could e.g. make lamp-ultrajson thing that would be optimized to process json structures through the lamp stack as fast as possible. In my proposal, you would need to create httpd-ultrajson, mariadb-ultrajson, and php-ultrajson packages first before you could make the compound rpm lamp-ultrajson that would Require the *-ultrajson base packages while also providing a binding config to ease the setup after installation. I don't think it is bad to have those base packages placed somewhere explicitly so that you can install them individually but let's say you don't want that for some reason and you only want the end-product, which is the lamp-ultrajson package/module. Then I can see a purpose in the modulemd file being a very advanced build-script which can be used to launch a parallel well-tailored build of base packages to produce the final set of packages which are required for the given use-case (the use-case being e.g. ultra-fast json processing through a stack). But this is something else than parallel-availability and modularity shouldn't aim at multiple targets at the same time because it will hit neither in the end. If this is the purpose - to provide optimized applications by tailoring their compile-time options for a given use-case - then I would suggest that the resulting compiled base rpm packages are, in the end of each module build, merged into a single rpm by overlaying their file-system contents. That way you can provide something which is useful and which also plays nice with the rest of the rpm eco-system. Like this, you can also completely avoid solving unsolvable problems with potential conflicts between modular and non-modular content. Also, instead of an rpm, you could optionally merge the results into something else than an rpm, e.g. a container image. If these are the products of module builds (single rpms/images), then I can see things starting to come together at lest to my understanding. Modulemd would be basically a script to create a specifically focused application packed in an rpm created from a distributed build of other rpms. This resulting rpm could then be placed into a "stream" that I have proposed here as other rpms which are built by standard means (rpmbuild -bb). The process of creation would differ but the end result would be of the same type as what standard rpm build process gives. That is, for sure, useful to keep things simple and I would even say "maintainable". clime > > P > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
