On Sat, Jul 10, 2010 at 7:44 AM, Anas Nashif <[email protected]> wrote: > 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.
What is *recommended* is irrelevant in this discussion, what matters is what is *mandatory*. See below: >> s/for ALL packages// >> >> And we're fine. You didn't answer to that. Focus. Do not reply to this mail unless you absolutely answer that. Can you do that? Can you update the guideline to say: "It is NOT mandatory to use spectacle" >>> 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. Answer this: can I take the spec file out of an openSUSE SRPM and put it back to OBS without modifications? >> 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. I thought the purpose of a .changes file was to replace the %changelog. >> However, the format of OpenSUSE's .changes is different than MeeGo's, right? You didn't answer this rather critical question. >>> 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. And after you have made such modifications, such as not building docs, you can push the changes back the the upstream spec. Some might not be appropriate, but some might. >> 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. Even openSUSE guys claim it was a mistake: http://old.nabble.com/Convert-existing-changelog-from-.spec-file-to-.changes-file-td26030622.html >>> 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. What two ways? If you read carefully I didn't mention any .changes file there. I said %changelog *only*. >> 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. Ah, I thought it was the other way around. >> 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. No it doesn't. I have tried to explain you many times why it's not the same thing but you don't seem to understand. I give up. >> 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 No comments on this? >> OBS is also perfectly fine with the %{dist} tag as it's automatically >> dropped: > > Thats why it does not make any sense in meego :) I doesn't matter to MeeGo. What happens if I do: Releases: 1%{?dist} -> Nothing, OBS replaces it Releases: 0 -> Nothing, OBS replaces it Releases: wakawaka -> Nothing, OBS replaces it So what doesn't make sense in MeeGo is to enforce a guideline on the Releases field; if it's not used *at all*, people can put whatever they wan there. Why not allow something that other distros commonly use? > 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. So you are saying if it's a plain number, like 10, then OBS would replace it with something like 10.1? 10.1 -> 10.1.1? Well, in that case OBS can do s/%{?dist}//: and then OBS can use the release number: problem solved. >> ----------------------------------------------------------------- >> I have the following modifications for dsp-tools.spec: >> 3c3 >> < Release: 1%{?dist} >> --- >>> Release: 3.1 >> ----------------------------------------------------------------- You also didn't answer this. And the guideline says: --- There is no need for the %{dist} macro in the release field. This is also handled directly by the build system. --- Which means %{?dist} is *not* forbidden. >>> bugs.meego.com >> >> I figured that much, but which component. Care to reply to this? >>> 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? You forgot the context of that argument in which you said you were compiling for Fedora: > We have a few packages in meego that are made to build for every distro out > there, like banshee and the mono packages used on netbook. >> Without %changelog, there's no compliance. > > There is a %changelog, get a source rpm, unpack it, look in the spec file. You are just not listening. -- Felipe Contreras _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
