Felipe, 

On Friday 09 July 2010 19:35:39 Felipe Contreras 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.


thats not correct - see for example the package git from openSUSE:Factory on 
build.opensuse.org
$ osc ls openSUSE:Factory git

apache2-gitweb.conf
completion-wordbreaks.diff
git-1.7.1.tar.bz2
git-daemon.init
git-nohardlink.diff
git-python-install-fix.diff
git.changes                <--- .changes
git.spec                      <--- .spec
git.xinetd
sysconfig.git-daemon
usr.share.git-web.gitweb.cgi


We've the .changes and the .spec files .

> 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.

We tried now multiple time to explain: 
* spectacle is a parser for YAML style files and will generate .spec
* its used as TOOL for packages requiring simple ./configure; make ; make 
install
* it doesn't replace .spec - it creates them.
* both files are there - .spec and .yml .
* the builder uses the .spec not the .yml 
* again: it doesn't replace the specfile 
* you're invited and encouraged to use this tool to ease daily work
* common tools help to share workload - already thought about ?
* finally: it doesn't replace .spec
 
[...]
> 
> 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.
See example above from openSUSE - 
they even developed the .changes feature ! IIRC its in use since 11.0 !

> 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.

It is RPM. Through the new pkgconf() features we even need to hardcode less 
BuildRequires.
I'd even say through this we're more distro-agnostic than others atm 
(less hardcoded BuildRequires -> less differences in pkg-naming!).

> 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.

Cool down !  

Best,
Jan-Simon
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev

Reply via email to