Hi,

> -----Original Message-----
> From: [email protected] [mailto:meego-packaging-
> [email protected]] On Behalf Of ext Anas Nashif
> Sent: Friday, April 01, 2011 6:07 PM
> To: Gabriel M. Beddingfield
> Cc: [email protected]
> Subject: Re: [meego-packaging] Dropping yaml
> 
> > Is there some place that actually details out /why/ spectacle is a
> good idea and /how/ it is saving people time? The MeeGo wiki just makes
> these claims as if its obvious... but after working with spactacle, I
> don't think it's so obvious.
> >
> > Good features I've seen:
> >
> >  - Builders (if one exists)
> >
> >  - Some of the pre/post stuff avoids newbie mistakes
> >    (like not calling ldconfig after installing libs)
> >
> >  - Nice patch management (add patch in one place,
> >    instead of two places in the spec file.)

- Automatically pulls sources from the specified URL?

> > Drawbacks:
> >
> >  - It does not fully encapsulate the .spec file.
> >    You need both a .yaml and a .spec.  I would have
> >    expected this to be a transformation... not some
> >    strange patch-in-place.
> 
> for most cases it does, the file list can also be encapsulated in the
> yaml file.

Yes, as I learned from a source that must remain unnamed.
You have to wrap every file list entry with fugly double quotes, but hey, you 
must bend the syntax to suit the simple and easy tool, right?

> Maybe we just need to clarify the rules and move forward. I personally
> hate it when a package fix or change gets blocked because of something
> like that, this is counter-productive.
> Take the guidelines on the wiki and come up with a better proposal if
> you wish, but lets not waste too much time on something like that. At
> the end of the day, what matters is the spec file, and if it is well
> maintained and kept up with the rest of the distribution, then I do not
> care how it was created, using spectacle or manually or whatever.

Nice and reasonable, thanks.

I'd like to propose the following:

* It should be explicitly allowed to change the primary packaging from yaml to 
spec or vice versa, as long as the main maintainer for the package agrees to 
the change. Hacking yaml+spec is a bad practice and should be discouraged.

* The role and direction of Spectacle should be revised. I think it's very 
useful to be able to easily bootstrap an initial spec for a new package, or get 
a generated spec for reference against up-to-date templates and policies, and 
Spectacle could be a good tool for these purposes. Yaml can also be used as the 
description format for simple and formulaic packages (especially if the tag 
names are made less idiosyncratic). But attempting to squeeze all spec 
capabilities into Spectacle source format only results in complication and 
pain, and urging people to edit two files for one purpose is not good either. 
So, the hack-and-merge workflows should be removed, and wrapping of advanced 
spec features should be descoped. If it cannot be made to look good in yaml, it 
does not belong there, and the package maintainers with advanced needs should 
switch to the real thing for their own good. Spectacle is there to jumpstart 
them.

Best regards,
  Mikhail
_______________________________________________
MeeGo-packaging mailing list
[email protected]
http://lists.meego.com/listinfo/meego-packaging

Reply via email to