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(a)lists.fedoraproject.org
https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks