On Tue, Mar 20, 2018 at 10:06 AM, Michal Novotny <cl...@redhat.com> 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? 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 <jkal...@redhat.com> wrote: > > > > > > On Mon, Mar 19, 2018 at 4:43 PM, Adam Williamson > > <adamw...@fedoraproject.org> 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@lists.fedoraproject.org > >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > > > > > _______________________________________________ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
