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:
- COPR owner
- Playground contributor
- 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@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks