[arch-general] Depends on foo-bar=10.0-3
Hi,
why does a package from official repositories mentions what version of
a dependency is required? Since the actually optional dependency
pulseaudio by upstream often is required as a hard dependency, for no
sane reason, I installed a dummy package years ago, to workaround time
consuming workarounds. Today I tried to install something and part of
the dependency chain of stuff I don't need is pulseaudio-bluetooth. It
doesn't matter, I'm willing to install pulseaudio-bluetooth, instead
of building another dummy package or rebuilding something. Why does the
package pulseaudio-bluetooth dedicated mentions pulseaudio=10.0-3? Why
not simply mentioning "pulseaudio" without the version?
Note! I'm not asking anybody not to do it like this! I only want to know
the reason for mentioning a version of a dependency, for packages from
official repositories, since I don't know any reason. IOW I only want
to learn.
Regards,
Ralf
[rocketmouse@archlinux aur]$ pacman -Si pulseaudio-bluetooth
Repository : extra
Name : pulseaudio-bluetooth
Version : 10.0-3
Description : Bluetooth support for PulseAudio
Architecture : x86_64
URL : https://www.freedesktop.org/wiki/Software/PulseAudio/
Licenses : GPL
Groups : None
Provides : None
Depends On : pulseaudio=10.0-3 bluez bluez-libs sbc
Optional Deps : None
Conflicts With : None
Replaces : None
Download Size : 50.91 KiB
Installed Size : 173.00 KiB
Packager : Jan de Groot
Note! I'm not asking anybody not to do it like this! I only want to know the reason for mentioning a version of a dependency, for packages from official repositories, since I don't know any reason. IOW I only want to learn. AFAIK the dependecy is there in this case, because pulseaudio-bluetooth is a module for pulseaudio. Therefore it is built using that specific version of pulseaudio, which is why you need this dependency for
Hi Ralf, On 2017-08-14 10:36:45 (+0200), Ralf Mardorf wrote: pulseaudio-bluetooth to work properly. Guess due to Arch being rolling release this could be skipped, but I have not tried that yet ;-) Maybe less error prone? Best, David -- https://sleepmap.de
why does a package from official repositories mentions what version of a dependency is required? Because it may be that it is working only with that particular version. The two common scenarios are:
1) The package requires protocol/API/ABI/header/etc-level compatibility. You may see this like: foo=a.b.c and bar=a.b.c are coming together. 2) The package requires newer API (≥X), but it is also known that available versions newer than X have some bug that prevent the package from working (≤X). Effectively one gets =X in requirements. It seems that you case is the first one.
On Mon, 14 Aug 2017 14:03:45 +0200, mpan wrote:
why does a package from official repositories mentions what version of a dependency is required? Because it may be that it is working only with that particular version.
That doesn't explain why it is needed or in any way useful for a package provided by official Arch repositories? Partial upgrades are unsupported [1]. Actually it could be vary annoying, if packages now start including the version of a dependency. I didn't notice that packages mention dependency versions for at least the last 4 years [2]. It's not the only dummy package I'm using for at least that long. [1] https://wiki.archlinux.org/index.php/System_maintenance#Partial_upgrades_are... [2] [rocketmouse@archlinux ~]$ pacman -Qi pulseaudio | grep D | grep -v al Description : Dummy package Depends On : None Build Date : Sun 18 Aug 2013 06:06:40 PM CEST
why does a package from official repositories mentions what version of a dependency is required? Because it may be that it is working only with that particular version. That doesn't explain why it is needed or in any way useful for a package provided by official Arch repositories? Partial upgrades are unsupported [1]. Actually it could be vary annoying, if packages now start including the version of a dependency. I didn't notice that packages mention dependency versions for at least the last 4 years [2]. It's not the only dummy package I'm using for at least that long. No one said people are allowed to install only packages from official repos. You have yourself delivered an example of a package that had pulseaudio listed in its provides entry.
Another case: sometimes multiple packages in the official repo may deliver the same thing: see jre8-openjdk and jre7-openjdk — different versions of the java-runtime. Or mysql (*now* no longer in official repos) and mariadb: different implemenations of the same flavour of RDBMS.
On Mon, 14 Aug 2017 15:03:01 +0200, mpan wrote:
Another case: sometimes multiple packages in the official repo may deliver the same thing: see jre8-openjdk and jre7-openjdk
Those packages provide java-runtime and java-runtime-openjdk, but you could install both packages and if a package needs a special version of java-runtime and java-runtime-openjdk, it depends either on the package jre8-openjdk or jre7-openjdk. This is something completely different.
On 08/14/2017 08:48 AM, Ralf Mardorf wrote:
On Mon, 14 Aug 2017 14:03:45 +0200, mpan wrote:
why does a package from official repositories mentions what version of a dependency is required? Because it may be that it is working only with that particular version.
That doesn't explain why it is needed or in any way useful for a package provided by official Arch repositories? Partial upgrades are unsupported [1]. Actually it could be vary annoying, if packages now start including the version of a dependency. I didn't notice that packages mention dependency versions for at least the last 4 years [2]. It's not the only dummy package I'm using for at least that long.
Well, it is also done for gcc and gcc-libs. It's generally only used for things like split packages where there is an extremely strict codependency between the two packages. -- Eli Schwartz
On 14 August 2017 at 13:48, Ralf Mardorf
On Mon, 14 Aug 2017 14:03:45 +0200, mpan wrote:
why does a package from official repositories mentions what version of a dependency is required? Because it may be that it is working only with that particular version.
That doesn't explain why it is needed or in any way useful for a package provided by official Arch repositories? Partial upgrades are unsupported [1]. Actually it could be vary annoying, if packages now start including the version of a dependency. I didn't notice that packages mention dependency versions for at least the last 4 years [2]. It's not the only dummy package I'm using for at least that long.
Yes, partial upgrades are unsupported, but in practice this still happens, usually not deliberately. For instance, I will quite often do a "pacman -S <package>" without doing a full system update first, assuming that *probably* nothing important has changed since the last update. It's a sloppy practice, but humans cut corners: it happens. When a plugin relies on a potentially unstable ABI (not many applications offer stable ABIs), specifying that the plugin package requires that exact version of the application will ensure that mistakes like this don't happen. If I see an error like "package x requires y=1.2.3" when installing a package, the first thing I'll try is a system update, an obscure segfault is avoided, and everyone's happy. So the failsafe does the job. It's good defensive practice by the packaging team, I think. Paul
On 08/15/2017 03:47 AM, Paul Gideon Dann via arch-general wrote:
Yes, partial upgrades are unsupported, but in practice this still happens, usually not deliberately. For instance, I will quite often do a "pacman -S <package>" without doing a full system update first, assuming that *probably* nothing important has changed since the last update. It's a sloppy practice, but humans cut corners: it happens. When a plugin relies on a potentially unstable ABI (not many applications offer stable ABIs), specifying that the plugin package requires that exact version of the application will ensure that mistakes like this don't happen.
If I see an error like "package x requires y=1.2.3" when installing a package, the first thing I'll try is a system update, an obscure segfault is avoided, and everyone's happy. So the failsafe does the job. It's good defensive practice by the packaging team, I think.
What. No, the packaging team explicitly does not care about you, and official policy is to yell at you for having once upon a time run pacman -Sy without -u That is pretty deliberate on your part. -- Eli Schwartz
Den 15 aug. 2017 13:46 skrev "Eli Schwartz"
Yes, partial upgrades are unsupported, but in practice this still happens, usually not deliberately. For instance, I will quite often do a "pacman -S <package>" without doing a full system update first, assuming that *probably* nothing important has changed since the last update. It's a sloppy practice, but humans cut corners: it happens. When a plugin relies on a potentially unstable ABI (not many applications offer stable ABIs), specifying that the plugin package requires that exact version of the application will ensure that mistakes like this don't happen.
If I see an error like "package x requires y=1.2.3" when installing a package, the first thing I'll try is a system update, an obscure segfault is avoided, and everyone's happy. So the failsafe does the job. It's good defensive practice by the packaging team, I think.
What. No, the packaging team explicitly does not care about you, and official policy is to yell at you for having once upon a time run pacman -Sy without -u I'm guessing that happens a lot though. Being explicit about the version for a module makes pacman itself handle the most obvious problems that would generate "support requests". If something did break long after you did those steps it may not be obvious you installed the main package and the module out-of-sync, so someone may yell at the packagers or devs for "introducing regressions/bugs" causes by this. Maybe they do care about the time they would spend yelling back at you if this was not the case? That is pretty deliberate on your part. -- Eli Schwartz
OT: If for some reason proper quoting should be broken, top-posting could be a better solution, than very broken bottom-posting, let alone the broken interleaved posting of a previous reply.
I have no patience for reading people's broken quoting. Please try again, this time using a decent email client.
Someone call 911, another trainwreck thread on [arch-general]. Watching the carnage ensue is not as much fun as it should be though, so long after responders no longer pretend to care. That being said, we should definitely add a versioned dependency between fuse-common and sshfs. Just because my mirror failed me recently. cheers! mar77i
2017-08-15 15:32 GMT+02:00 Eli Schwartz
I have no patience for reading people's broken quoting. Please try again, this time using a decent email client.
The Gmail Android app sends HTML emails - which I forgot when replying during my lunch break - and I'm sorry for that, but it's not something I can do anything about. Unless maybe if you know of another app which behaves exactly the same in all other regards. I'm not asking you to find one, as you probably have no patience to help me look for one either, just name it if you know it. Would love to use one, if it's FOSS, but so far everything else I've seen has not even been half-decent in comparison. I could also suggest you instead use a client capable of displaying HTML, then the quotes don't look that bad, but you're probably just as unlikely to change as anyone else. ;)
On 08/15/2017 02:58 PM, Henrik Danielsson via arch-general wrote:
I could also suggest you instead use a client capable of displaying HTML, then the quotes don't look that bad, but you're probably just as unlikely to change as anyone else. ;)
Oddly enough, I use Thunderbird, which displays HTML mail fine, and viewing the message source tells me that message was formatted as (mangled) plaintext. ¯\_(ツ)_/¯ -- Eli Schwartz
Oddly enough, I use Thunderbird, which displays HTML mail fine, and viewing the message source tells me that message was formatted as (mangled) plaintext. The one I sent first, from my phone, clearly has the header for "multipart/alternative" and then after the delimeter we have "text/html" and "quoted-printable". My first response to you, and this one, are sent as text/plain from
2017-08-15 21:10 GMT+02:00 Eli Schwartz
Em agosto 15, 2017 15:58 Henrik Danielsson via arch-general escreveu:
The Gmail Android app sends HTML emails - which I forgot when replying during my lunch break - and I'm sorry for that, but it's not something I can do anything about.
Actually it sends multipart MIME, both HTML and text.
Unless maybe if you know of another app which behaves exactly the same in all other regards. I'm not asking you to find one, as you probably have no patience to help me look for one either, just name it if you know it. Would love to use one, if it's FOSS, but so far everything else I've seen has not even been half-decent in comparison.
Ditch HTML and use only text.
I could also suggest you instead use a client capable of displaying HTML, then the quotes don't look that bad, but you're probably just as unlikely to change as anyone else. ;)
The text part of your email was completely mangled, there is no quoting whatsoever. And the HTML part does not get through because mailman removes attachments for obvious reasons. Now, can we please get back on topic on this thread? Cheers, Giancarlo Razzolini
participants (8)
-
David Runge
-
Eli Schwartz
-
Giancarlo Razzolini
-
Henrik Danielsson
-
Martin Kühne
-
mpan
-
Paul Gideon Dann
-
Ralf Mardorf