On Tue, Mar 20, 2018 at 3:31 PM, Jan Kaluza <jkaluza@xxxxxxxxxx> wrote: > On Tue, Mar 20, 2018 at 10:06 AM, Michal Novotny <clime@xxxxxxxxxx> wrote: >> >> The question here is why don't we actually implement the modularity >> the simple way. >> >> Let's suppose I would like to make nodejs-8 available in EPEL7. >> >> The most effortless way would be to create subdirectory called 8 at >> src.fedoraproject.org/rpms/nodejs >> with the updated spec file and sources for the bumped major version of >> the nodejs package. > > > What if your module contains packages coming from multiple SRPMs and they > depend on each other? Well, my module wouldn't be coming from multiple SRPMs because my module is just a normal package. The problem with modularity is that the name does not really fit what it does, which is kind of important because wrong names make implementation much harder as you cannot rely on your common sense. When I think of a module, rpm ultimately comes to mind. That's kind of a unit that makes up an operating system. I highly doubt modularity can change it unless it invents its own package format. So I think it would be good to call it differently even in the tooling. So let's try to figure out a better name for modulemd. Basically, the final product of modulemd is a repo with some built rpm packages in it (if I saw the latest development correctly, we were squashing multiple of those repos into a single one but we wouldn't need to do that). For users, a repo represents something like a stream of content. So streammd would be already a better name. But even a better name would be coprmd because you can think about the current "modulemd" as a copr (community project) being formally described in a file. Product of a copr project is also a repo so it fits. Stream name here: https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L13 is basically a project name. The content specified here: https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L305 are basically definitions of SCM packages. And then there are some fields like: version: 20160927144203 context: c0ffee43 which doesn't really belong there imho but instead belong to the final built repository (= copr snapshot) as a part of repodata (if anywhere). So I think it would be good to keep talking about packages when we talk about modules. clime > > Jan Kaluza > >> >> >> For fedpkg to be able to upload and download sources for that >> subdirectory (submodule), the attached >> single-line patch is needed in python-rpkg. There are a few more >> changes needed to make srpm >> importing work but it should be basically almost done as well. >> >> Koji then just needs to learn how to build DistGit repositories >> containing submodules where >> submodule is any subdirectory containing a spec file. When Koji >> discovers all the submodules >> in a repository, it can start an srpm and a consequent rpm build for >> each of them. >> >> It is a very similar approach to what find_packages from python >> setuptools implements. It >> recognizes subpackages based on the presence of __init__.py file. The >> only difference here >> is that we will be recognizing subpackages (=submodules) by the >> presence of *.spec file. >> >> Everything else should be pretty much the same otherwise. Koji builds >> nodejs-6 and nodejs-8 rpms >> both with el7 disttag and both of these can go through the Bodhi >> update process separately. >> >> Of course, the question is if you can actually build and run nodejs-8 >> in EL7 successfully but >> I think that will always be a problem no matter what the implementation >> is. >> >> clime >> >> On Mon, Mar 19, 2018 at 8:08 PM, Jan Kaluza <jkaluza@xxxxxxxxxx> wrote: >> > >> > >> > On Mon, Mar 19, 2018 at 4:43 PM, Adam Williamson >> > <adamwill@xxxxxxxxxxxxxxxxx> wrote: >> >> >> >> On Mon, 2018-03-19 at 10:58 +0100, Stanislav Ochotnicky wrote: >> >> > On Mon 19 Mar 2018 09:38:58 AM GMT Fabio Valentini wrote: >> >> > > So you think having to send a request to a web service instead of >> >> > > just >> >> > > parsing a string locally with one line of code is a good trade-off >> >> > > for >> >> > > allowing dashes? >> >> > >> >> > This has been mentioned several times in this thread and I think >> >> > there's >> >> > a misunderstanding around this. >> >> > >> >> > So: When your tool/whatever works with modules it will have to have >> >> > module metadata available in some form. >> >> >> >> What if I don't want to work with modules at all, just with information >> >> about modules? >> >> >> >> What if I just want to write a tool that parses fedmsgs about module >> >> builds in Koji and does something that depends on module names, streams >> >> and versions? (e.g. some sort of changelog thing) >> > >> > >> > Your tool can use good old buildsys.build.state.change fedmsg with the >> > well >> > known name/version/release fields like this: >> > >> > >> > https://apps.stg.fedoraproject.org/datagrepper/raw?topic=org.fedoraproject.stg.buildsys.build.state.change >> > >> > That's staging, because it's easier for me to find the module builds >> > there >> > :). >> > >> > Unfortunatelly, Koji does not add "type" field there, so you cannot find >> > out >> > if that's module or not. But in case your tool is doing general >> > changelog >> > per Koji build, it will work quite well with modules without you even >> > noticing you are working with modules. >> > >> > In case of tools, you can even query koji using its api and pass the >> > name/version/release there, instead of NVR. >> > >> > If you query Koji for the module build, you will actually find whole >> > module >> > metadata in "extra" part of the build. >> > >> > In case you are OK with using MBS fedmsgs, you can use the fedmsgs Nils >> > already sent in this thread. >> > >> > Regards, >> > Jan Kaluza >> > >> >> -- >> >> Adam Williamson >> >> Fedora QA Community Monkey >> >> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net >> >> http://www.happyassassin.net >> >> _______________________________________________ >> >> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx >> >> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx >> > >> > >> > >> > _______________________________________________ >> > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx >> > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx >> > >> >> _______________________________________________ >> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx >> > > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
