Considerations: <br>I agree with the issues related to orig tar.gz and ITP. <br>I believe the name would be ganeti-os-debian-etch. <br>Because it is one os script for ganeti, it isn't one instance. <br>The instance will be created using this script.
<br><br>And i don't see why not use the version of this package to describe the api. <br>That way we could use the API number as major package version. <br>ex: API 4, version xyz, package release 2<br>ganeti-os-debian-etch version
4.xyz-2<br><br>We can use conflict on ganeti with ganeti-os-debian-etch (< 4) for example.<br><br>We can use Provide to provide ganeti-os virtual package. <br>That way future os scripts also provide this package. <br>
<br><div><span class="gmail_quote">2008/1/18, Iustin Pop <<a href="mailto:iusty@k1024.org">iusty@k1024.org</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Fri, Jan 18, 2008 at 04:52:12PM +0100, Guido Trotter wrote:<br>> On Fri, Jan 18, 2008 at 03:29:58PM +0100, Iustin Pop wrote:<br>><br>> Ciao,<br>><br>> > First, using svn-buildpackage we need to have the orig tarball as a
<br>> > tar.gz and not just as a simple .tar. This is not nice to fix (we<br>> > provide a different tarball than upstream), and from next upstream<br>> > version we'll switch to .tar.gz; it's more consistent this way.
<br>> ><br>><br>> That's good! :) :) Well, for now changing the tarball is not too bad, I've done<br>> worse things to "orig" tarballs! :) :)<br>he he :)<br><br>> > Second, I think there should be an ITP first, right? I'll open one. Do
<br>> > we agree that the name should be ganeti-instance-debian-etch?<br>> ><br>><br>> LGTM<br>ok, will open the ITP.<br><br>> > Third, lintian/linda warn me that an arch-independent package installs
<br>> > something under /usr/lib. I don't know a nice workaround to this, except<br>> > by extending ganeti's search patch to cover also /usr/share/ganeti/os.<br>> ><br>><br>> That's probably the right way to go...
<br>ok, I'll add that to the ganeti pkg.<br><br>> > Also, should we make some relationship between what os-api is provided<br>> > by ganeti and what an OS provides? For example, ganeti recommends<br>> > ganeti-os-api version 4 (a virtual package); ganeti-instance-debian-etch
<br>> > has a Provides: ganeti-os-api.<br>> ><br>><br>> I don't think there can be versioned provides.. Can there?<br><br>Good point. It seems not:<br>"So, a Provides field may not contain version numbers, and the version
<br>number of the concrete package which provides a particular virtual<br>package will not be looked at when considering a dependency on or<br>conflict with the virtual package name."<br><br>Therefore, we could have the virtual names "ganeti-os-api-4", next time
<br>"ganeti-os-api-5", etc.<br><br>But I'm also not sure about this section:<br>"All packages should use virtual package names where appropriate, and<br>arrange to create new ones if necessary. They should not use virtual
<br>package names (except privately, amongst a cooperating group of<br>packages) unless they have been agreed upon and appear in the list of<br>virtual package names. (See also Virtual packages - Provides, Section<br>7.4)".
<br><br>Could we say here that the ganeti packages are using these names<br>"privately"?<br><br>iustin<br><br>_______________________________________________<br>Pkg-ganeti-devel mailing list<br><a href="mailto:Pkg-ganeti-devel@lists.alioth.debian.org">
Pkg-ganeti-devel@lists.alioth.debian.org</a><br><a href="http://lists.alioth.debian.org/mailman/listinfo/pkg-ganeti-devel">http://lists.alioth.debian.org/mailman/listinfo/pkg-ganeti-devel</a><br></blockquote></div><br><br clear="all">
<br>-- <br>Leonardo Rodrigues de Mello<br>jabber: <a href="mailto:l@lmello.eu.org">l@lmello.eu.org</a>