d-u wants to remove digikam kipi-plugins

[stm2468]

Hi,

a dist-upgrade wants to remove digikam and kipi-plugins, because libkdcraw23 is missing:

Has anybody else this situation? I have it since 2-3 weeks.




apt-cache depends digikam
  Depends: <libkdcraw23>

apt-cache depends kipi-plugins
  Depends: <libkdcraw23>


apt-cache search libkdcraw23
 nothing


apt-cache showpkg digikam
Versions:
4:3.5.0-90r1.1 (/var/lib/apt/lists/ftp.spline.de_pub_siduction_fixes_dists_unstable_main_binary-i386_Packages)
4:3.5.0-3+b3 (/var/lib/apt/lists/http.debian.net_debian_dists_unstable_main_binary-i386_Packages)
4:3.5.0-3+b2 (/var/lib/dpkg/status)

[devil]

My guess is, you are missing the kdenext repository.  Add

Code: [Select]

deb http://packages.siduction.org/kdenext/ unstable main to your sources.list.


greetz
devil

[stm2468]

Hi devil,

yes, the repository has been missing. And using this repository will not remove any of the mentioned packages, instead brings me a lot of new kde stuff.
But without the kdenext repo, the packages should be consistent also, I guess...

Martin

[devil]

That would be a debiaqn problem though. The digikam upstream does not care much about distributions, so a lot of times stuff is broken that we might fix faster than debian. Hence the situation.


greetz
devil

[michaa7]

Hm, I have the same problem, since months. I understand how I could solve the problem using KDE-next (which I don't want to).

My question is a general question: If siduction fixes a problem like this, does/did anyone file a bug report to *Debian*?

[melmarker]

@Michaa7
Why? digikam will ever be a monster to pack - and the debian team do a great work, but some dependencies have to go through the normal process in debian - which causes breaks. We can be - and are faster with this.

æstm2468
We thinking of a general solution for siduction - regarding the kdenext-repo. Btw - its not recommended to use siduction kde without the kdenext-repo - but this is a totally different thing.

[michaa7]

@Michaa7
Why?

Seriously? That's one of the dumbest answers I've ever heard here in the forum.

We can be - and are faster with this.

Then you should *officially* throw away any statement telling users siduction aims to improve *Debian* by filing bugreports, patches, whatever ...

[melmarker]

Ok - damit das klar ankommt: Die Frage Warum? war nicht blöd - das weiss nun wirklich jeder, der sich ansatzweise mit der Materie Digikam beschäftigt hat - und sich vielleicht auch noch mit der Arbeitsweise Debians auskennt. Es ist also recht klar, dass Du nicht zu dieser Gruppe gehört.

 Nur so als kleine Nachfrage: Wann hast Du Deinen letzten Debian-Bug gemalt? Nur irgendeinen, der debian verbessert? Wann hast Du das letzte Mal mit irgendeinem Upstream zusammengearbeitet, damit Pakete nicht fehlerhaft in debian ankommen? Fällt Dir nicht ein? Komisch. Bei mir ist das grade mal wenige Stunden her.

[michaa7]

Ok - damit das klar ankommt: Die Frage Warum? war nicht blöd - das weiss nun wirklich jeder, der sich ansatzweise mit der Materie Digikam beschäftigt hat - und sich vielleicht auch noch mit der Arbeitsweise Debians auskennt. Es ist also recht klar, dass Du nicht zu dieser Gruppe gehört.

You could have paint some chinese ideographs, would be the same, still BS.

Nur so als kleine Nachfrage: Wann hast Du Deinen letzten Debian-Bug gemalt? Nur irgendeinen, der debian verbessert? Wann hast Du das letzte Mal mit irgendeinem Upstream zusammengearbeitet, damit Pakete nicht fehlerhaft in Debian ankommen? Fällt Dir nicht ein? Komisch.

How do *you* know? You can't, you don't and you are wrong, completely. And exactly the fact that you are basing your BS on wild, wrong assumptions proves how damn stupit your "why" was and still is!

Instead of encouraging people (I am not talking about *me* because I sure as hell don't need *your* whatever to file a bug report when it seems appropriate to me) to participate in Debian you diminish the importance of bug reports with your stupid "why".

Bei mir ist das grade mal wenige Stunden her.

fine.
I couldn't file my last bug report yesterday, because reportbug-gtk here is broken due to http://forum.siduction.org/index.php?topic=4351.0 (and yes, i know theres is a text-only version of bugreport, I prefere and I am *used* to the gtk version due to various bugeports I filed over time). And when reportbug-gtk is working again here I will file the bugreport regarding the package at which you so farsightedly asked: why?

[melmarker]

Noch mal zum mitmeisseln:
* KDE Siduction != debian sid
* Digikam Siduction != debian sid
* Fehler in Derivativen gehören nicht in Debians BTS.

Es ist sinnlos, dazu einen Bug an Debian zu melden, die können damit nichts sinnvolles machen. Aber das willst und wirst Du nicht begreifen. Also fang wieder an klugzuscheissen, wenn Du weisst, wovon Du redest. Sonst ist das nur Zeitverschwendung.

[michaa7]

Noch mal zum mitmeisseln:
* KDE Siduction != debian sid
* Digikam Siduction != debian sid
* Fehler in Derivativen gehören nicht in Debians BTS.

Yes, you are right, no news to me. Was cut in stone beforehand.

What led me to assume there *is/was* a Debian bug was:

Hi devil,

yes, the repository has been missing. And using this repository will not remove any of the mentioned packages, instead brings me a lot of new kde stuff.
But without the kdenext repo, the packages should be consistent also, I guess...

Martin

and

That would be a debiaqn problem though. The digikam upstream does not care much about distributions, so a lot of times stuff is broken that we might fix faster than debian. Hence the situation.

greetz
devil

But you are right, the bug which prevented (!) digikam from being installed here seemed to be siduction (not Debian), because I couldn't update with the fixes repo enabled, I couldn't update with the kde-next repo enabled, I couldn't update with both enabled. But tonight I could update with *both* those siduction repos *disabled*.

Your amount of work is appreciated, but there remains some doubt whether or not some solutions are smart.

[melmarker]

 

... but there remains some doubt whether or not some solutions are smart.

Full ACK. And the solution with the splitted repositories is somewhat smart and somewhat absolutly braindead.
For people outside of siduction a separated kdenext repository is a fine thing - for us it turns out that it is a pita to maintain. So we are working on a solution, but not now, it will take some days and some discussions to clean up that mess.

And once again - if the kdenext-repo isn't in the list - for what reasons ever - there is no clean upgrade path against debian. The isos are built with the kdenext repo used. (Stupid idea - but we thought it was a good one - sorry for that). So there will be no need to report any bugs that result from this mess to debian, we should and will solve this by ourself.

there are some descisions in debian mostly about dev-packages/libs which make it hard (or impossible) to have a clean upgrade path. In such cases we decicded that we are leading with versions. Everything is mostly ok, if debian catch up later. But for this we must have our repo in place, if not: ugly things happend.

[michaa7]

... but there remains some doubt whether or not some solutions are smart.

Full ACK. ...So there will be no need to report any bugs that result from this mess to debian, we should and will solve this by ourself.
...

Thanks. This is clear speech which will be understood by people who have no insight in what you (and others) are trying to do. Your above criticized statement (Why?...but some dependencies have to go through the normal process in debian - which causes breaks. We can be - and are faster with this.)  seemed contrary to what you say now.

[ralul]

Perhaps we should open a more general thread:
How siduction and debian packages should mangle
- directed by priorities or revision numbers (santas -r90 versions should trump debian)
- or different repositories

[melmarker]

@ralul - there is no need for a more general thread - all needed facts are known and we discuss the possible technical solution for this at the moment. The goal is not to interfere with debian whenever it is possible. Therefore we need a nearly bulletproof solution for our repo. Sorry - but we haven't so far. In case of KDE there are historical reasons like kde/experimental-snapshot. And with the growing of siduction our knowledge grow too.

The other question at the moment is the price of maintaining this repo - the price measured in effort and man hours. This price should be as low as possible - not only for maintaining the repos, also for the efforts needed for releases and the maintainance of these releases. We have limited ressources and should do the best to use them as effective as possible.

In my humble opinion we should organize this as debian do: on big repo with all packages in. This repo should provide unstable, next and experimental. Beside that we should use snapshot repos like debian. At the moment we discuss advantages and disadvantages of this approach. To be clear: In case of KDE siduction will be the leading repository with the most current versions and the highest version numbers (as it is now with kdenext). This will lead sometimes to collisions with debian - but we think not to often. The current mess is that we build our releases with kdenext - and when one decide to delete this repository from the sources, this will eventually break some dependencies - bad luck.  In all other cases debian and siduction packages should and will coexist. Thats the price we have to pay, beeing sometimes ahead of debian.