Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Overengineering & more dependency hell

User discussion about Debian Development, Debian Project News and Announcements. Not for support questions.
Message
Author
shadowking
Posts: 496
Joined: 2009-05-06 11:34

Overengineering & more dependency hell

#1 Post by shadowking »

Debian developers. Why not respect upstream ? Wine should be wine.deb not a gazillion packages.

I made a remark about it before and today i had to install different versions. Normally I run the binary from winehq which is just wine1.x.deb . Then i made the mistake for downgrading to debian lenny wine instead of v1.01 from WineHQ. Okay that went well. Then I decide I need my old v1.1.26 from winehq. So i dpkg -i wine1.26.deb

dpkg: considering removing libwine in favour of wine ...
dpkg: no, cannot proceed with removal of libwine (--auto-deconfigure will help):
wine-utils depends on libwine (= 1.0.1-1)
libwine is to be removed.
dpkg: regarding .../wine_1.1.26~winehq1-1_i386.deb containing wine:
wine conflicts with libwine
libwine (version 1.0.1-1) is present and installed.
dpkg: error processing /home/ng/downloads/binary/wine/wine_1.1.26~winehq1-1_i386.deb (--install):
conflicting packages - not installing wine
Errors were encountered while processing:
/home/ng/downloads/binary/wine/wine_1.1.26~winehq1-1_i386.deb
Installation failed
Press enter to continue




See ? Over engineering . Why not stick to KISS ? More complexity more breakage for NOTHING!
YEs i know i shouldn't dpkg - i etc. But that isn't the point - it won't happen if debian wine was a single .deb


Now apt-get remove libwine*

The following packages will be REMOVED:
libwine libwine-alsa libwine-cms libwine-gl libwine-gphoto2 libwine-ldap libwine-print libwine-sane pptview wine wine-bin
wine-utils
0 upgraded, 0 newly installed, 12 to remove and 0 not upgraded.
After this operation, 56.8MB disk space will be freed.
Do you want to continue [Y/n]?


Oh great - It gonna rip out pptview as well. All this for absolutely nothing. Which other distro does this ? Debian might be all this and that , but sooner or later the package maintainer stuffs things by specifying unneeded deps causing breakage.

User avatar
Telemachus
Posts: 4574
Joined: 2006-12-25 15:53
Been thanked: 2 times

Re: Overengineering & more dependency hell

#2 Post by Telemachus »

@Shadowking: Please send any and all serious bugs or feature requests to the appropriate mail list or bug tracker.

@ All others: do NOT feed the troll.

(Note: that's just me talking, no moderation involved.)
"We have not been faced with the need to satisfy someone else's requirements, and for this freedom we are grateful."
Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

shadowking
Posts: 496
Joined: 2009-05-06 11:34

Re: Overengineering & more dependency hell

#3 Post by shadowking »

Ok I'll send bug reports & won't feed the troll as well. Whatever you say.

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

Re: Overengineering & more dependency hell

#4 Post by julian67 »

Actually nothing is broken except your consciousness.

Multiple wine components:

Consider: my system uses alsa, so do I really want to install wine drivers for oss, esd, nas and jack?

I don't have an ISDN card, should I be obliged to install the driver for it anyway?

Debian is a binary distribution of an entire OS and necessary applications, with highly effective and mature package management. If you step outside of the managed Debian package environment then you should have a clue as to what you're doing. You don't.

It's very common for packages in Debian and several other types of distro such as Red Hat/Fedora and Suse to modularise packages. There are advantages and disadvantages and different people will find one or the other preferable (many people won't really care). If this is really a problem for you, and I hope it is, then the solution is easy. Quit using Debian or any other distro which modularises packages and go use Slackware. They will be as unimpressed by your analytical abilities and attitude as everyone here, but you might get a grace period before people realise you're like this all the time.
Wisdom from my inbox: "do not mock at your pottenocy"

shadowking
Posts: 496
Joined: 2009-05-06 11:34

Re: Overengineering & more dependency hell

#5 Post by shadowking »

libwine oss is 279k FFS

Who is wrong or right ? Who knows. OK suppose debian is right.

Why does wineHQ and mepis make non-mod .debs. I am not saying that is right or wrong but to have incompatibility because everyone is an egomanic and cannot standardize on nothing. I could care less if winehq had a modular .deb like debian as long as the 2 don't conflict.

I am not saying debian wine team is to blame . My gut feeling is that its too complex for the winehq guys to replicate even though they like too. The incompatibility is wrong . So wineHQ sucks / so does mepis. No one gives a toss at the end of the day in FOSS. there is zero compatibility of anything. At least someone should be TRYING to make stuff a little more compatible and easier to install - if i was a package maintainer i would.

You say i don't know what iam doing but thats bullshit. its been a while since i even installed the debian wine and several yrs ago had a similar problem.

HIghly effective: I give you this: Yes only when running the flagship stable release with nothing else added. But then effective for maybe a server.

User avatar
saulgoode
Posts: 1445
Joined: 2007-10-22 11:34
Been thanked: 4 times

Re: Overengineering & more dependency hell

#6 Post by saulgoode »

As a general criteria I tend to agree that "respecting upstream" is extremely beneficial -- for what it's worth this is the main reason that I've been using Slackware as my main distro for the last dozen or so years. I personally find that the fractionating and patching of upstream offerings that most distros perform interferes (moreso than helps) with my maintenance and administration duties. That is not to say that I consider Debian's packaging approach misguided -- it certainly has its benefits. Plus I have great admiration for the overall quality of Debian repositories, but merely find Slackware a better fit to my abilities, or lack thereof.

Nonetheless, for the specific situation you describe, the difficulty encountered seems not at all attributable to Debian's packaging guidelines, nor to Debian developers (insofar as they are working within Debian). The problem appears to me to be owing to decisions made during the upstream packaging.

Upstream-supplied packages of development releases should be packaged so as to be stand-alone and not interfere with any system-installed software. It should not install to /usr (probably not even /usr/local), and it should not result in the removal or upgrading of any system-installed applications, configurations, or dependencies. The purpose of upstream development releases should be unit testing of their software, with integration testing being more the duty of the distro.

Of course, this is merely my opinion, but a good many upstream projects refuse to release binary packages of development versions for this very reason (the GIMP project is the first to spring to mind). Such releases typically result in bug reports having very little, if anything, to do with the software under development, and often attributable to lack of distro-specific understanding on the part of the reporter. Addressing such bug reports is generally a waste of time for both the upstream project and the distro developers.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian Kernighan

shadowking
Posts: 496
Joined: 2009-05-06 11:34

Re: Overengineering & more dependency hell

#7 Post by shadowking »

@saulgoode - Thanks for your insight into this. I recently tried slackware and liked it. Didn't work out a plan to change distro yet.

Actually: A while back i wanted to use some development WINE build but debian didn't have wine-unstable at that time, So off to wineHQ I went.

User avatar
BioTube
Posts: 7520
Joined: 2007-06-01 04:34

Re: Overengineering & more dependency hell

#8 Post by BioTube »

Whether you agree with the way Debian splits Wine, the removal of pptview is because you just removed the package it depends on(thus apt is functioning correctly). Of course, there is a repo available for use with apt to avoid this situation in the future.
Image
Ludwig von Mises wrote:The elite should be supreme by virtue of persuasion, not by the assistance of firing squads.

User avatar
Korrode
Posts: 107
Joined: 2010-03-03 19:20
Location: Australia

Re: Overengineering & more dependency hell

#9 Post by Korrode »

If you'd prefer the style from upstream be always stuck to, why are you running Debian?

Along with looking into Slackware, If you prefer package management with dependency checking, you may want to look into Arch as well.
http://www.archlinux.org/

shadowking
Posts: 496
Joined: 2009-05-06 11:34

Re: Overengineering & more dependency hell

#10 Post by shadowking »

I am still checking out slackware . It can also be armed with slapt-get or similar. Some derivatives do just that .

After the latest openoffice breakage on backports, I'm convinced on my belief that a single .deb slackware style would be better. I stress: removing OO and installing the official .debs from upstream was HEAVEN compared to the nightmare of dealing with broken repos. On slackware distros openoffice is always a single .tgz and same in windows or OSX - it works so well . Now backports screwed up because the whole thing needs a high level QA -you need to give deps tracking to everything you split. Usually its only a matter of time before some packager makes an error and you are screwed. Yeah I know that backports isn't fully supported but they are still debian devs and goes back to what i originally said - looks to be more trouble than its worth.

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

Re: Overengineering & more dependency hell

#11 Post by julian67 »

I notice that while (allegedly) repos are broken, backports is screwed up, packagers make errors....you're still perfect! Odd. Odder still is how numerous others use the same packages provided by the same packagers via the same repos but don't manage to screw it up. I wonder where the problem lies.
Wisdom from my inbox: "do not mock at your pottenocy"

shadowking
Posts: 496
Joined: 2009-05-06 11:34

Re: Overengineering & more dependency hell

#12 Post by shadowking »

You are back to your frigging WorksForMe(tm)


You can see for yourself:

http://mirror.linux.org.au/backports.or ... ffice.org/


3.2 is not ready . Xfce4.6 was the same for 6 months - only amd64 and partial i386 (there are posts here about this you can search yourself).


Others not reporting : Why ? 1- They are used to broken crap 2- they are scared of ridicule
Ever thought that a LOT of bugs just never go reported because this ?

The following packages have unmet dependencies:
openoffice.org-style-galaxy: Depends: openoffice.org-core (>= 1:3.2.0~beta) but 1:3.1.1-15+squeeze1~bpo50+1 is to be installed.
openoffice.org-common: Conflicts: openoffice.org-base (< 1:3.2.0) but 1:3.1.1-15+squeeze1~bpo50+1 is to be installed.
Conflicts: openoffice.org-calc (< 1:3.2.0) but 1:3.1.1-15+squeeze1~bpo50+1 is to be installed.
Conflicts: openoffice.org-core (< 1:3.2) but 1:3.1.1-15+squeeze1~bpo50+1 is to be installed.
Conflicts: openoffice.org-draw (< 1:3.2.0) but 1:3.1.1-15+squeeze1~bpo50+1 is to be installed.
Conflicts: openoffice.org-impress (< 1:3.2.0) but 1:3.1.1-15+squeeze1~bpo50+1 is to be installed.
Conflicts: openoffice.org-math (< 1:3.2.0) but 1:3.1.1-15+squeeze1~bpo50+1 is to be installed.
Conflicts: openoffice.org-writer (< 1:3.2.0) but 1:3.1.1-15+squeeze1~bpo50+1 is to be installed.

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

Re: Overengineering & more dependency hell

#13 Post by julian67 »

Yes Debian works for me, and many others. But nothing works for you. We know this because you've been telling us since the day you joined this forum. Everything is crap, everyone else is desperately stupid, the users are idiot victims, the packagers are careless idiots, the developers are a gang of user hating morons, we're all retards one way or the other. We're especially stupid because we don't even notice how terrible it all is, while you do. But you persist in using this awful system made by and favoured by idiots, retards and fanatics. What does that make you?
Wisdom from my inbox: "do not mock at your pottenocy"

shadowking
Posts: 496
Joined: 2009-05-06 11:34

Re: Overengineering & more dependency hell

#14 Post by shadowking »

You see:

openoffice.org-style-galaxy_3.2.0-4~bpo50+1_all.deb

ALL = all arch right ? Now it needs openoffice-core 3.2 BUT core has ONLY AMD64

shadowking
Posts: 496
Joined: 2009-05-06 11:34

Re: Overengineering & more dependency hell

#15 Post by shadowking »

julian67 wrote:Yes Debian works for me, and many others. But nothing works for you. We know this because you've been telling us since the day you joined this forum. Everything is crap, everyone else is desperately stupid, the users are idiot victims, the packagers are careless idiots, the developers are a gang of user hating morons, we're all retards one way or the other. We're especially stupid because we don't even notice how terrible it all is, while you do. But you persist in using this awful system made by and favoured by idiots, retards and fanatics. What does that make you?

Don't worry , I've already decided to leave. At least i can say i did all i could. Actually i managed to fix some of my initial problems - that involved custom kernels, vga drivers, compiling etc. This is because the stable release doesn't properly support my hardware and the testing release is too problematic in a different way. Stable + backports is also broke . What is left ?

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

Re: Overengineering & more dependency hell

#16 Post by julian67 »

Bye!

...oh wait...it's April 1st
Wisdom from my inbox: "do not mock at your pottenocy"

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

Re: Overengineering & more dependency hell

#17 Post by julian67 »

shadowking wrote: Don't worry , I've already decided to leave.
But will we still be able to see the kids on the weekend? And what about the CD collection? All the good stuff is mine btw. You can keep your Boney-M Greatest hits and your Westlife collection.
Wisdom from my inbox: "do not mock at your pottenocy"

shadowking
Posts: 496
Joined: 2009-05-06 11:34

Re: Overengineering & more dependency hell

#18 Post by shadowking »

And why is it that 'unsupported' .debs from Sun Micro, Opera, Skype have never broken on me and the touted debian backports break ? Because they are professional companies, hiring professional packagers to do a proper job ?

You know somehow i doubt backports made an 'error' 3 times now each time with same large packages . I doubt they adopt the same policy as in debian stable/testing where stuff has to be uploaded COMPLETE.

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

Re: Overengineering & more dependency hell

#19 Post by julian67 »

You're still here! OK you can have the car and the curtains and the signed 1st edition Danielle Steel.
Wisdom from my inbox: "do not mock at your pottenocy"

shadowking
Posts: 496
Joined: 2009-05-06 11:34

Re: Overengineering & more dependency hell

#20 Post by shadowking »

I am outta here. So long.

Post Reply