GNOME.org
 

Re: [Ekiga-list] Debian packages

Rick Pasotto wrote:

On Tue, Dec 30, 2008 at 08:39:54PM +0100, Eugen Dedu wrote:

Rick Pasotto wrote:

gnome-desktop-environment depends on ekiga (>= 2.0.12)

Since 'aptitude install ekiga-snapshot' removes ekiga,
gnome-desktop-environment becomes BROKEN and the installation would
REMOVE 47 other packages.

As far as I'm concerned, this means that ekiga-snapshot is NOT
installable.

I think that the problem is that the version number for
ekiga-snapshot is 0-20081220-1 which is less than 2.0.12. Perhaps if
the version number were changed to something greater that 2.0.12 (eg,
3-20081220-1) then the problem would go away.

Hi,

Increasing the version of ekiga-snapshot does not work.

There are two solutions: - either stay as we are now.  Note that only
gnome-desktop-environment  is removed (+old pwlwib/opal), not 47
packages!! - or do not use ekiga-snapshot anymore, but ekiga (while
ptlib and opal  are still named -snapshot, to avoid soname problems).
Note that this  will not be intrusive or conflict with debian package,
because the  version will be carefully chosen.

What do people prefer??


Sorry to hear that changing the version number doesn't work. I'm not
really clear on exactly how the debian version number punctuation works.
Did you try using 3.0.0 or even 2.9? Perhaps the fact that the first
non-digit character is a '-' makes a difference.
Provides does not yet work with version number. Here is a discussion on chat from this evening:
<eugen-busy> hi! Pkg A in debian depends on pkg B (>= 2.0.12). I want to create pkg B-svn, which conflicts with B. Pkg B-svn has version 1.0. The question is: what can I do so that when users install B-svn, A still remains on the system? I have changed the version of B-svn to 3.0 and make it Provides and Conflicts and Replaces B, however it still does not work (I hope I am not wrong in my check). <mgoetze> eugen-busy: why don't you give B version 2.0.12+svn-r1234 or something? <HE> eugen-busy: If you want to change the package name, you need to change A. The problem you are seeing is a misssing (?) feature in dpkg, usually called "versioned provides" <eugen-busy> I made it version 3.0, still does not work. Why 2.0.12+... should work? 
<eugen-busy> I cannot change A, A=gnome-desktop-environment
<Rhonda> eugen-busy: versioned-depends can't be resolved by provides.
<HE> eugen-busy: Why not? gnome-desktop-environment is easy to change, even I can do so :) 
<eugen-busy> HE, is it a joke or serious?
<Rhonda> I don't see a joke statement here.
* Piet has quit (Remote host closed the connection)
<eugen-busy> so the correct solution is that I provide also gnome-desktop-environment with a modified Depends field? 
<eugen-busy> (only for pkg A)?
<HE> eugen-busy: I'm more or less serious. It's not a problem to change g-d-e, it's just a package like every other (actually, it's even less complex, being a meta-package). And I can change it because I'm a Gnome maintainer :) 
<eugen-busy> it is not sufficient :o)
<eugen-busy> I work on ekiga-snapshot packages.
<HE> eugen-busy: Yeah, just change g-d-e to Depend on B (>= 2.0.12) | B-svn
<Rhonda> eugen-busy: versioned depends can't be resolved by provides. So if your B-svn must conflict with B and packages have versioned depends on B, these depending packages need to get changed. <eugen-busy> HE, could you change g-d-e to depend on ekiga (...) | ekiga-snapshot, provided that ekiga-snapshot is not in debian repository, but on ekiga own servers? 
<ron> do we really need two ekiga packages in the same suite?
<ron> why not just upload the -svn version to experimental?
<eugen-busy> it's because I change it very often, say once per week
<ron> so?  that's what we have version numbers for
<ron> and what we have experimental for if it's really that volatile
* glandium (~mh 2a01:e35:8a5f:8130:21d:e0ff:fe26:f4b) has joined #debian-devel <eugen-busy> snapshots are not so stable, I think it's better to have them outside debian. 
<HE> eugen-busy: Errr ... Please file a bug
<ron> ok, but you can still version them so they just naturally replace the earlier 'stable' snaphots 
<eugen-busy> HE, about what?  e-snapshots for g-d-e or versioned provides?
<ron> then you don't have to jump through name | name | name hoops, it all Just Works as it's supposed to 
<eugen-busy> ron, there is another impossible problem:
<eugen-busy> ekiga depends on 2 libs, and these libs change the soname each month, so I cannot call them -snapshot too; and this pollutes package space (a binary package each month * 2) 
* jackyf has quit (Quit: KVIrc 3.4.0 Virgo http://www.kvirc.net/)
* cortana (~sam 62-31-63-21 cable ubr12 aztw blueyonder co uk) has joined #debian-devel <HE> eugen-busy: There's already a row of bugs about versioned provides, so just file one against g-d-e <ron> do they _release_ with a new soname each month, or are people just abusing it for intermediate snapshots at _every_ change? 
<eugen-busy> they _do_ release each month.  I know it's not good, but...
<eugen-busy> they _do_ release a new soname each month. I know it's not good, but... <ron> well then you are just going to build up a huge collection of libfoo{1,2,... 999} packages. that still doesn't mean you need a -snapshot package for either the libs or ekiga. just version them normally 
* mkrist has quit (Quit: leaving)
<ron> I agree it's ugly, but there is no need to make it unnecessarily uglier. it's just like normal versioning and releases, just at 20x normal speed. it all still works the same fast or slow though <eugen-busy> -snapshot was the simplest for me... So you propose me to use the correct naming, such as libpt2.4.3 for the lib name, is that right? <paravoid> eugen-busy: you could always provide ekiga packages from your repo 
<paravoid> with the "ekiga" name
<eugen-busy> hi paravoid!
<paravoid>  :)
<ron> just name them so that dpkg --compare-versions always gets them in the right order <ron> then your ~svn snapshots replace older stable versions, and newer stable versions (when they come) will replace the ~svn ones from in-between 
<ron> s/name them/version them/
<ron> which is what you asked for initially, just much, much, simpler :)
<eugen-busy> paravoid, how can I name them? The simplest was to have libpt-snapshot, libopal-snapshot, ekiga-snapshot and that's all. <ron> paravoid: btw. did you nag HE about getting the * fix into testing? (: <eugen-busy> To resume: the simplest think still seems to me to wait the versioned provides in g-d-e... (no need to change packages name). And all this in my own repo. * hanska__ (~hanska host246-175-dynamic 2-79-r retail telecomitalia it) has joined #debian-devel 
* hanska is now known as Guest77
* hanska__ is now known as hanska
<eugen-busy> thanks to all and happy new year
* Guest77 has quit (Ping timeout: 480 seconds)
<ron> you don't even need to wait. if your versions increment as dpkg --compare-versions thinks they should, this will Just Work too <eugen-busy> ron, I still don't understand. I create ekiga-svn v. 3, and g-d-e depends on ekiga (>=2.0.12), and ekiga-svn conflicts with ekiga. This does not work! <eugen-busy> This does not work = when installing ekiga-svn, ekiga is removed and g-d-e too! <ron> right, so don't do that. instead just package ekiga 3.0~svn-whatever and let nature do the rest 
<ron> 3.0~svn _is_ >= 2.0.12 if my math doesn't entirely fail me
<ron> and < 3.0 in the eyes of dpkg
* tester (~tester 78-83-87-170 spectrumnet bg) has joined #debian-devel
* tester has quit ()
<paravoid> eugen-busy: what ron said. just name them with a version that will allow it to upgraded but newer versions from Debian to supersede yours <paravoid> i.e. current Debian version (2.0.12-1) < your version < newer Debian version (e.g. 3.0-1) 
<eugen-busy> I am still thinking if it is ok...
<paravoid> your version could be 2.1-1~snapshot1 or 3.0-1~snapshot1 etc.
<paravoid> libopal and libpt will obviously have different names
<paravoid> because of the upstream sillyness wrt sonames
<eugen-busy> yes...
<eugen-busy> Yes, I think it's ok. THANKS a lot, ron, it's the simplest solution. <paravoid> but that shouldn't affect you, since the whole thing with libary package naming is designed to allow coinstabillity 
<eugen-busy> Ok, THANKS a lot, ron; and paravoid.
* m42 (~m42 a81-84-75-214 cpe netcabo pt) has joined #debian-devel
<eugen-busy> No need to fill a bug to g-d-e...


The number of packages that depend on gnome-desktop-environment will
vary from system to system. On my machine the following 45 packages
would be removed:

arj{u} at-spi{u} cheese{u} dasher{u} dasher-data{u} dmz-cursor-theme{u}
eog{u} festival{u} festlex-cmu{u} festlex-poslex{u} festvox-kallpc16k{u}
file-roller{u} gcalctool{u} gconf-editor{u} gedit{u} gedit-common{u}
gnome-accessibility{u} gnome-accessibility-themes{u} gnome-core{u}
gnome-desktop-environment gnome-network-admin{u} gnome-orca{u}
gnome-power-manager{u} gnome-screensaver{u} gnome-themes{u} gok{u}
gstreamer0.10-tools{u} gucharmap{u} iceweasel-gnome-support{u}
libalut0{u} libavahi-ui0{u} libbrlapi0.5{u} libglew1.5{u}
libgnome-speech7{u} libgtk-vnc-1.0-0{u} libswfdec-0.6-90{u} libxevie1{u}
mousetweaks{u} python-brlapi{u} python-gtksourceview2{u}
python-pyatspi{u} rss-glx{u} swfdec-gnome{u} unace{u} vinagre{u}
There's something wrong. Please check carefully that arj for ex. depends on g-d-e. Do you use apt-get remove (instead of dpkg -P) by chance?? This is a wrong (and dangerous) way to remove packages in my opinion. 

--
Eugen
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]