On Fri, Jul 9, 2010 at 11:04 PM, Greg KH <[email protected]> wrote: > On Fri, Jul 09, 2010 at 10:23:45PM +0300, Felipe Contreras wrote: >> On Fri, Jul 9, 2010 at 8:53 PM, Greg KH <[email protected]> wrote: >> > On Fri, Jul 09, 2010 at 08:35:39PM +0300, Felipe Contreras wrote: >> >> So one would expect that such distro-agnostic spec file can be use in >> >> MeeGo too, right? >> > >> > Yup, and it works just fine, I built a number of MeeGo packages just >> > this week, in the openSUSE obs, and they work wonderfully. >> >> No, I meant the other way around. > > No, I think I got it backwards. > > I took some packages, some with no .spec file, and some with a .spec > file from other distros, and built them just fine for MeeGo with no > problems.
Yeah, as I said: they *build* fine. >> Suppose git wasn't packaged, the official tarball has a git.spec that >> is distro-agnostic. If you were to submit it to Fedora for inclusion, >> it would be accepted, I suppose it would also be accepted on openSUSE. >> >> But on MeeGo it would be rejected. > > If it doesn't meet the guidelines, that makes sense. > > But note that lots of the existing MeeGo .spec files meet the fedora and > openSUSE guidelines, so I don't see the issue here. That's impossible. Fedora needs a %changelog section. Show me one package that has it. >> >> Wrong. MeeGo doesn't use spec files at all (which is how RPMs are >> >> supposed to be built). Instead, maintainers are supposed to write >> >> spectacle YAML files which are used in turn to generate spec files. >> > >> > Um, they do? Since when? Did something change since this past >> > Wednesday when I built these packages? >> >> Oh, they build fine, as OBS doesn't need spectacle YAMLs. The issue is >> about MeeGo _guidelines_, according to Arjan van de Ven, the spectacle >> YAMLs should also be there[1]. >> >> [1] http://lists.meego.com/pipermail/meego-packaging/2010-July/000411.html > > Ok, then create that as well, what's the big deal? That despite of already knowing my way around RPM, now I have to learn a new custom format that only MeeGo uses. And maintaining two files instead of one for every package for no known reason except "it's needed by build tooling". It might not be a big deal for me, but it doesn't scale, specially for the people that maintain dozens of packages. Spectacle was supposed to make things easier, not harder. And what happens if the spectacle file doesn't match the spec file one? Having an alternative custom format for the people that are not happy with spec files is fine, but building infrastructure relying on it while there's the standardized and widely spec files, seems like a bad idea to me. Don't you think? -- Felipe Contreras _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
