Playground Repo Requirements Document

[Alek Paunov]

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)?

Kind regards,
Alek

[1] https://lists.fedoraproject.org/pipermail/devel/2013-May/183195.html