Bug#646325: gst-plugins-good0.10: diff for NMU version 0.10.30-2.1

2011-12-03 Thread Philipp Kaluza
tags 646325 + patch
tags 646325 + pending
thanks

Dear maintainer,

I've prepared an NMU for gst-plugins-good0.10 (versioned as 0.10.30-2.1)
and will ask for an upload to DELAYED/2. Please feel free to tell me if
I should delay it longer.

Greetings from the BSP,
  Philipp Kaluza

diff -Nru gst-plugins-good0.10-0.10.30/debian/changelog gst-plugins-good0.10-0.10.30/debian/changelog
--- gst-plugins-good0.10-0.10.30/debian/changelog	2011-11-09 15:20:38.0 +0100
+++ gst-plugins-good0.10-0.10.30/debian/changelog	2011-12-03 11:42:34.0 +0100
@@ -1,3 +1,11 @@
+gst-plugins-good0.10 (0.10.30-2.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Add Replaces/Breaks to gstreamer0.10-gconf for old 
+gstreamer0.10-plugins-good (Closes: #646325)
+
+ -- Philipp Kaluza deb...@ghostroute.eu  Sat, 03 Dec 2011 10:34:02 +
+
 gst-plugins-good0.10 (0.10.30-2) unstable; urgency=low
 
   [ Sebastian Dröge ]
diff -Nru gst-plugins-good0.10-0.10.30/debian/control gst-plugins-good0.10-0.10.30/debian/control
--- gst-plugins-good0.10-0.10.30/debian/control	2011-11-09 15:20:38.0 +0100
+++ gst-plugins-good0.10-0.10.30/debian/control	2011-12-03 11:44:44.0 +0100
@@ -53,6 +53,8 @@
 Section: sound
 Depends: ${misc:Depends},
  ${shlibs:Depends}
+Replaces: gstreamer0.10-plugins-good ( 0.10.30-2)
+Conflicts: gstreamer0.10-plugins-good ( 0.10.30-2)
 XB-GStreamer-Version: ${gstreamer:Version}
 XB-GStreamer-Elements: ${gstreamer:Elements}
 XB-GStreamer-URI-Sources: ${gstreamer:URISources}
@@ -79,7 +81,7 @@
  ${shlibs:Depends},
  gstreamer0.10-audiosink,
  gstreamer0.10-plugins-base,
- gstreamer0.10-gconf
+ gstreamer0.10-gconf (=0.10.30-2)
 Recommends: gstreamer0.10-x
 Replaces: gstreamer0.10-plugins-bad ( 0.10.21.2), gstreamer0.10-plugins-really-bad ( 0.10.21.2), gstreamer0.10-plugins-good-doc ( 0.10.6-2)
 Conflicts: gstreamer0.10-plugins-bad ( 0.10.21.2), gstreamer0.10-plugins-really-bad ( 0.10.21.2)



Bug#402811: module-assistant: module package versions: epoch avoidable ?

2008-05-19 Thread Philipp Kaluza
Package: module-assistant
Followup-For: Bug #402811

Hi Ken,

thanks for your work on this.

For those of us who upload m-a generated module packages to a local apt
repository, an epoch will be confusing and not really add any recognition
value. For example, to stay with kqemu, my users might see the following
availabe versions in aptitude:

2.6.25+1.3.0~pre11-1
1:2.6.25+1.3.0~pre10

While it's clear that the epoch one is higher and the preferred one, it's
confusing as to why this is.

I propose that you do not implement the epoch, and instead put an
additional string between the kernel version and the module source
version, for example like so:
kernelversion+modass+modulesourceversion

Verification:
$ dpkg --compare-versions 2.6.25+1.3.0~pre11-1 '' 2.6.25+modass+1.3.0~pre10 
 echo yes
yes

Another possibility:
$ dpkg --compare-versions 2.6.25+1.3.0~pre11-1 '' 2.6.25.modass+1.3.0~pre10 
 echo yes
yes

Both options would make it clear that this is a m-a built package, give
this package a higher priority than linux-modules-* supplied packages,
and avoid introducing an epoch.

Thank you for your consideration.
Ciao,
  Philipp



PS: incidentially, something like 2.6.25+m-a+1.3.0~pre10 would also
work, but of course is very very wrong if there's not also a debian revision 
appended.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]