Bug#515214: Bug#523960: equivs is surely not the solution to this problem. Recommends: is.
Hello David, All of that said, it's very likely that we will downgrade the depends to recommends, just not right now. We have actual important bugs like totally broken installs that we want to deal with first. It's been 5 months since then, could you please give us an update on this? I'm sure that some people have refrained from upgrading X.org because of this, but this is getting to the point of ridiculous for them. Regards, -- Pierre Ynard Une âme dans un corps, c'est comme un dessin sur une feuille de papier. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515214: Bug#523960: equivs is surely not the solution to this problem. Recommends: is.
Hi, Just following up to David Nusinow comment (not directed at him but this seems to be where the main defencive stance on this seems to be): X.org not only runs on fat workstations but also on embedded device where you as less abstraction layers and diskspace used as possible. Debian always claims to be the _universal_ operating system and it should also package X.org to be universal. Debian is not (a desktop focussed) Ubuntu. Note that this is the direction that upstream is heading in. The design is conceptually quite simple. The X server asks the system, in this case via hal, to enumerate input devices are present and gets them enumerated back. And for the platforms where hal does not exist? Xorg is not just available for Linux. I'm all for making it easier for refugee's from other OS's to get onto the Linux bandwagon, but the moment you start removing choice from those already on the bandwagon, something is going seriously wrong. This is greater than some the Debian 'policy' document, we are stepping onto point four in Debian's *social* contract. Maybe that's just my opinion, I read that bit in the social contract as 'choice', others might read it differently. The argument regarding get used to dependencies...it's the way of the world is, that's fine *when* the functionality (such as PCI scanning) might have been stripped from Xorg altogether and it simply will not compile without it. The reality is that the Xorg folk know HAL is not available on all the platforms Xorg runs on and so it's a compile time option. If you can show us all that HAL is available on *all* platforms where Xorg runs and that the Xorg folk are about to make HAL a dependency[1], then you probably would get no grief from making Debian match things up (hell it work have a non-functioning Xorg which is not an option). Currently though the situation is quite different and it turns out that even with this automagical detection support compiled in, it can be disabled at runtime and people can continue to *choose* to use their handcrafted xorg.conf files. So why are we forcing people to use stuff that is un-needed? Doing this would be no different to forcing people to install Java and Flash when Iceweasel is installed because hey everyone wants to use YouTube. :-/ Remember, with your position you are also harming the embedded and low spec'ed machine folk. I do not think people with small amounts of NAND flash for storage space will appreciate having a lot of unnecessary guff installed[2]. Debian runs on 11 different architectures, life's not a x86 with 2GB of RAM. I left that 'other' OS eight years ago exactly for these reasons as I did not like have the decision making process made by someone else. If Xorg decide to make HAL an actual dependency, then we will all deal with that ourselves (probably in the form of a witchhunt and burning down to xorg-hq)...until then there really is no reason why Debian should turn to the dark side. Hell just think about the hammering of the mirrors for all the extra package downloading you are causing... Some people pay for bandwidth. I (and it seems others too) can see so many arguments against making HAL a dependency but only see one in favour of it (and it's not like we are turning off any functionality in doing this). I think you will find that the main issue people have is that we think HAL/DBUS (and even what acpid has turned into) is fundamentally broken[3]. We have chosen to avoid it as Debian has enabled us to have this choice...that's why we use Debian. Cheers [1] there are already signs that other distros are getting fed up of the ghastliness that HAL has turned into. What are you going to do when the world starts getting a 'hard on' for DeviceKit instead? [2] http://www.embeddedarm.com/products/board-detail.php?product=TS-TPC-7390 ARM + 512MB NAND + LCD screen, and you want HAL on it? [3] we are too lazy to come up with alternatives, hell this might push us over the edge -- Alexander Clouter .sigmonster says: You will triumph over your enemy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515214: Bug#523960: equivs is surely not the solution to this problem. Recommends: is.
On Wed, 2009-04-15 at 20:24 +0200, Axel Beckert wrote: I herewith vote for demoting hal (#515214) and console-setup (#523960) to recommends. THIS IS NOT A FUCKING VOTE. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515214: Bug#523960: equivs is surely not the solution to this problem. Recommends: is.
Axel Beckert wrote: I really can't understand how someone can suggest to fake packages using equivs instead of using the Recommends: header as it's thought. The Policy says in 7.2 very clearly in all but unusual installations, so nobody can't use users who just want it work as argument. Debian's default is btw. to install recommended packages anyway. Another reason why users who just want it work are _no_ argument against using Recommends: header. Thank you so much for repeating exactly what other people have said. Given that the XSF must be collectively illterate, we didn't understand them the first dozen or so emails stating this, so the above was clearly necessary. X.org not only runs on fat workstations but also on embedded device where you as less abstraction layers and diskspace used as possible. Debian always claims to be the _universal_ operating system and it should also package X.org to be universal. Debian is not (a desktop focussed) Ubuntu. Note that this is the direction that upstream is heading in. The design is conceptually quite simple. The X server asks the system, in this case via hal, to enumerate input devices are present and gets them enumerated back. It then utilizes that hardware via the kernel rather than driving them itself with its own drivers. Note that this system was designed and implemented by a Nokia employee for an embedded system. It brings an enormous simplification to the overall operating system by putting things like keymaps in one place, and only having the kernel driving the hardware rather than both the kernel and the X server. It also makes it flexible with system changes, allowing hotplugging. Most importantly to Debian and the XSF, it means that we don't have to carry around a gigantic horrible bunch of shell script just to configure the system. All of this is a good thing. If you object to having the X server depend on external software, you're going to have to learn to like it, because the goal has been to decrease the amount of OS code that the server needs to duplicate in order to do its job. It no longer scans the PCI bus itself, but instead relies on libpciaccess to query the OS. It no longer carries its own build system, but relies on autotools. All of the video drivers are moving significant portions of themselves in to the kernel as well. If you can't deal with hal, then you'll have to write a replacement for it that allows the server to query the system in a transparent way, and also allows one to easily configure device-specific properties. This is something that hal currently does very well and the X server can not do otherwise. All of that said, it's very likely that we will downgrade the depends to recommends, just not right now. We have actual important bugs like totally broken installs that we want to deal with first. I herewith vote for demoting hal (#515214) and console-setup (#523960) to recommends. The BTS is not a voting system. - David Nusinow -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
