2010/7/9 Jan-Simon Möller <[email protected]>:
> On Friday 09 July 2010 19:35:39 Felipe Contreras wrote:
>> 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
What is not correct?
The fact that the maintainer of the git package in openSUSE decided to
diverge from the upstream distro-agnostic git.spec is his own decision
(and a bad one IMHO). There's an infinite amount if git.spec files
that would comply with openSUSE guidelines, the fact that the current
one is different from the upstream doesn't mean the upstream one
doesn't comply.
Not to mention that git is only an example. I'd be glad to submit one
of my distro-agnostic spec files to openSUSE review process to see if
it complies.
>> 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
There's a difference between maintaining a spec file, and maintaining
*both* a spec file and spectacle YAML.
If a spectacle YAML file is *completely optional* (regardless of the
complexity of the package), then that's fine for me; we can move on to
the other points.
>> 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!).
Yes, I agree the pkgconfig() capability is very nice, and indeed a
good move to make more packages distro-agnostic.
But you still require the whole %changlog section to be converted to
.changes, which to me is like one step forward, ten backwards.
>> 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 !
Don't let my communication style confuse you. I am not angry or anything.
I just think forcing people to diverge from upstream and common good
practices is a recipe for disaster. To this day there are still debian
packaging heroes trying to move Maemo closer to debian and I think
it's very nice the fact that I only need to change one line to make my
debian package ready for Maemo inclusion.
Cheers.
--
Felipe Contreras
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
