Playground Repo Requirements Document

Vít Ondruch vondruch at redhat.com
Wed Mar 5 09:45:37 UTC 2014


Dne 4.3.2014 23:14, Alek Paunov napsal(a):
> On 04.03.2014 14:09, Honza Horak wrote:
>> On 03/04/2014 03:14 AM, Alek Paunov wrote:
>>> P.S. Weather someone already works on JS interface (local web app) for
>>> generating/supporting .specs files based on local yumdb and the .spec
>>> grammar?. Is this a good idea? Showing rpmbuild and copr-cli command
>>> lines to the future packager?
>>
>> Hm, it seems like your imagination is on a higher level, in comparison
>> with mine -- could you elaborate a bit, please?
>>
>
> Sure, hope something bellow makes sense:
>
> - Formal .spec grammar [1] including system macros and Lua libs
>   as subgrammars
>
> - Work area: Structure editor following the above grammar
>
> - Flying palette:
>   - .spec sections, macros and snippets
>   - dependency points by searching/browsing yumdb.provides,
>     requires, etc.
>
> - The user drag/drops things from the palette to the structure
>
> - After dropping a construct, the user fills the blanks:
>   - using the upstream build instructions
>   - ideally, consulting the same sections from Fedora packages
>     belonging to the same stack (browsing existing specs parts)
>
> - Change log in own view, automatic change log entry
>
> - Iteration:
>   - spec save
>   - instead of directly issuing the commands, tool interactively
>     construct command lines (with educational goal behind) based
>     on their grammars
>     - rpmbuild -b.. --...
>     - createrepo
>     - .repo file
>     - copr-cli ...
>     - ...
>
> - Feature for parsing and reusing existing .spec as template instead
>   of blank page start
>
> Motivation:
>
> Regarding the classic - RPM based distribution mechanism, we are going
> to have 3-levels:
>
> 1. COPR owner
> 2. Playground contributor
> 3. Fedora packager
>
> Such a easy .spec editor would be mostly targeted towards the entry
> point: COPR owner. The Fedora packagers, thousands of experienced
> corporate developers and sysadmins are all used with the .spec format
> and it's ugliness, but for a new (let's say node.js generation,
> otherwise relatively knowledgeable) potential contributor .spec could
> be disappointing.
>
> Why JS - In my eyes, a structure editor would be easier to be build
> using the new browser technologies in comparison with the classic
> widget kits; Will looks equally (non :-) ) native under both KDE and
> Gnome or even (parts of) as a fp.o page.
>
> If it managed to be concept-proved on .specs (based solely on grammars
> and queries) may be will be possible to be reused for kikstarts and
> systemd units too (e.g. other basic Fedora artifacts)?

This sounds like fun project for GSoC. Have you considered to propose
this idea [1]? Of course there is OBS which does some of this already.


Vít



[1] http://fedoraproject.org/wiki/Summer_coding_ideas_for_2014



>
> Kind regards,
> Alek
>
> [1] https://lists.fedoraproject.org/pipermail/devel/2013-May/183195.html
>
> _______________________________________________
> env-and-stacks mailing list
> env-and-stacks at lists.fedoraproject.org
> https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks



More information about the env-and-stacks mailing list