On Fri, Mar 23, 2018 at 7:24 AM, Michal Novotny <clime@xxxxxxxxxx> wrote: > 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. That link should have pointed here: https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L233 > > 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
