On 2010-07-09, at 6:26 PM, Felipe Contreras wrote: > This mail was very badly formatted; all the reply levels are gone. > > On Sat, Jul 10, 2010 at 12:32 AM, Anas Nashif <[email protected]> wrote: >> http://wiki.meego.com/Packaging/Guidelines#Writing_a_package_from_scratch >> a few lines in the paragraph it reads: >> "It is NOT mandatory to use spectacle for ALL packages" > > That can be interpreted as: > It is mandatory only for SOME packages; the ones that are simple.
Those simple packages are recommended to use spectacle. > > s/for ALL packages// > > And we're fine. > >> 2) .changes instead of %changelog >> >> First, opensuse uses that, so we are not "entirely" different. > > Awesome; there's more divergence in RPM-based distros than I though. Why? SUSE rpms still have a spec file that has %changelog. <package>.changes is just part of the workflow leading to binary and source rpms. > I thought openSUSE could use the .changes, but didn't mind the > %changelog. While a package will not fail if there is a %changelog in the spec, it just does not make sense to use both. If developer A starts logging changes in %changelog and developer B prefers .changes then the results are not really optimal. > > However, the format of OpenSUSE's .changes is different than MeeGo's, right? > >> Second, the end result is a spec file in source rpm that has the contents of >> <package>.changes. (This way of packaging changes comes historically from >> the days when suse was based on slackware.) >> The build service looks for this file during build and adds the %changelog >> entry at the bottom of the spec file. >> So, end result is a spec file with %changelog. >> We adopted this, it is built-in in the build system and we are not doing >> anything out of the ordinary. It just works as expected. >> We are not really interested in changelog entries from the upstream, we just >> care for whatever is in meego, since day 0 of a package is in meego and not >> when an upstream developer created that spec. Now, since we had some spec >> files from other distros initially, you will notice many packages that still >> carry the original authors log entries, our goal to eliminate this and have >> MeeGo package all be original meego. > > It sounds very fancy if you put it that way, here's another way to put > it: the link to upstream's spec file is broken since day 0. What link to upstream? If distributions were a collection of upstream spec files then what would be the difference between Distro X and Distro Y? Back to you git example: The upstream spec could be taken as a starting point, but depending on what you want to support and what you have in your distro you might want to remove support for various things, package files in different locations, split package differently, not build docs and so on. You immediately end up with a spec that is in no way compatible with upstream spec file. That is how your distro will be different, because you have a goal and requirements that have to be reflected in that package. > > However, it's clear now to me that since this is a mistake done by > openSUSE rather than MeeGo, we are far beyond redemption. The chain > has been broken long ago. > You call it a mistake, I do not think it is a mistake. It is just another way for doing things. >> We do not have any requirements to make our specs build on anything but >> meego, however we make every attempt to not deviate from common practices >> and at aleast make it easy. One nice example is using pkgconfig and reducing >> the amount of explicit dependencies (those that are determined by rpm during >> build time automatically). > > Yes, that's nice. But since you are generating a %changelog anyway, > wouldn't it be sensible to allow a %changelog in the source spec? This will not work, since we want to do things in one way. As mentioned above, if we have 2 different ways to log changes, then we will be out of sync very fast. > > You could even have a script that converts from %changelog to > .changes; all you need is a stricter format of %changelog entries. > > But wait a second, there's already a tool for that: changelog2spec, > and guess what, OBS is already using it. Yes, that script converts .changes into %changelog. That is what we are using. And we have a script that convert %changelog to .changes that we use when we first import upstream packages or when a source rpm needs to be imported. > > You say you make "every attempt to not deviate", so what do you need > to not deviate from the standard %changelog section? Nothing, the > infrastructure is there, all you have to do is say "we allow it". We have %changelog in the source rpms and the built packages, that is what counts. > > Here's what openSUSE guys say about their genius .changes idea: > --- >> What about calling it spec2changelog and including it in the build >> package? changelog2spec is already there and also requires >> perl-TimeDate already. > > Argh, it's the same story over and over again. Why don't we drop the > .changes file in favour of using %changelog in spec? > --- > > http://old.nabble.com/Convert-existing-changelog-from-.spec-file-to-.changes-file-td26030622.html > > OBS is also perfectly fine with the %{dist} tag as it's automatically dropped: Thats why it does not make any sense in meego :) The problem is, if you have %{?dist}, then the original release number cant be used, when you have a number, which is the standard, then obs takes it and starts counting from there. I already said that in like 3 responses in this thread, here, and elsewhere, I am sure I have to repeat this again in a few posts. > > ----------------------------------------------------------------- > I have the following modifications for dsp-tools.spec: > 3c3 > < Release: 1%{?dist} > --- >> Release: 3.1 > ----------------------------------------------------------------- > >> bugs.meego.com > > I figured that much, but which component. > >> What guidelines? > > The guidelines of the packages you are compiling to (e.g. Fedora). We do not compile for fedora, we only compile for meego? Sure the fedora guidelines are helpful because they have lots of useful information and they are well maintained and I recommend looking at them, but we never said that follow those 100%. > > Without %changelog, there's no compliance. > There is a %changelog, get a source rpm, unpack it, look in the spec file. >> See above. You are not forced to submit a package in spectacle format, >> someone however might pick it up and do that if it makes sense. At some >> point we have converted over 300 packages in one shot using scripts, because >> it is really easy :) > > Right, if somebody automatically converts one of my spec files to > spectacle, fine, but the second somebody complains that the spectacle > file is not in sync with the spec file, I'll delete it. Thats great. Anas > > -- > Felipe Contreras > _______________________________________________ > MeeGo-dev mailing list > [email protected] > http://lists.meego.com/listinfo/meego-dev _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
