I don't really see what the big issue is. An RPM built for FC usually doesn't work on RH, nor would I try to install an RH rpm on SuSe.
Every distro has deviation in the names they choose for their packages. The fact that Meego seems to try to improve and make it easier to generate packages. I haven't read up on YAML, but I presume there's a reason beyond introducing a new feature just to be different and special. I've written spec files before and it's a particularly pleasant process. So I presume some tool parses the yaml file and generates a spec file. I don't see what the big deal is. You still end up with a spec file. You can take the spec file and turn around the generate RPMs for other distro after adjusting the library names and such. It's not like debian packages for debian are just like the ones for Ubuntu. *shurg*. Maybe you can elaborate a bit more about why you're so upset about this travesty. -- Samir On Fri, Jul 9, 2010 at 12:35 PM, Felipe Contreras <[email protected]> wrote: > Hi, > > So, AFAIK build.meego.com is closed, so many people probably don't > know what it means to maintain a package in MeeGo. Let's shine some > light on that. > > Say you have a package that has a spec file that is distro-agnostic, > like git does[1]. In Fedora, openSUSE, and other RPM-based distros, > all you need to do is make sure that the spec file conforms to their > guidelines, which are pretty similar among distros. Since there's so > much common ground, it's possible to have a distro-agnostic spec file > that conforms to the guidelines of many distros, and if not, probably > require minor modifications. > > So one would expect that such distro-agnostic spec file can be use in > MeeGo too, right? > > 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. > > It's still being discussed internally whether spectacle YAML files are > mandatory or not, but it seems they will be since "there is tooling > around them", so at the very least distro-agnostic spec files need to > be converted to spectacle YAMLs. > > Even if spectacle YAMLs are not mandatory, the %changes section would > have to be removed from the spec file, instead, a separate ".changes" > file should be provided which should follow a completely custom > format. > > At this point it's clear that whatever format ends up being used to > generate packages is not RPM, but a deviation from it. Needless to > say, it's pretty far from the conventions of the community of > RPM-based distros, and doesn't allow distro-agnostic spec files. > > Not to mention that the %{dist} tag is not allowed in the Release > filed of the spec file. Even if OBS automatically replaces the whole > Release field. So there's no functional reason; it's just a random > guideline. (it is enforced; my packages are rejected because of this) > > And note that this has nothing to do with OBS; build.meego.com is > happy to handle conventional spec files; my packages are built just > fine without warnings. > > It is purely a MeeGo guideline issue. > > I discussed this internally without much success, so now I bring it to > the community. What is your take on this? I think it's preposterous. > > [1] http://git.kernel.org/?p=git/git.git;a=blob;f=git.spec.in > [2] http://wiki.meego.com/Spectacle > [3] https://fedoraproject.org/wiki/Packaging/DistTag > > -- > Felipe Contreras > _______________________________________________ > MeeGo-dev mailing list > [email protected] > http://lists.meego.com/listinfo/meego-dev > -- -- Samir Faci *insert title* fortune | cowsay -f /usr/share/cows/tux.cow _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
