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?
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@lists.fedoraproject.org
>
>
>
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@lists.fedoraproject.org
>
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
