Playground Repo Requirements Document
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  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
> 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 ? Of course there is OBS which does some of this already.
> Kind regards,
>  https://lists.fedoraproject.org/pipermail/devel/2013-May/183195.html
> env-and-stacks mailing list
> env-and-stacks at lists.fedoraproject.org
More information about the env-and-stacks