Discussion:
Depends on foo-bar=10.0-3
(too old to reply)
Ralf Mardorf
2017-08-14 08:36:45 UTC
Permalink
Raw Message
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

[***@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 <***@archlinux.org>
Build Date : Sat 11 Mar 2017 11:21:44 PM CET
Validated By : MD5 Sum SHA-256 Sum Signature

[***@archlinux aur]$ pacman -Qi pulseaudio
Name : pulseaudio
Version : 2013.08.18-1
Description : Dummy package
Architecture : any
URL : None
Licenses : None
Groups : None
Provides : pulseaudio
Depends On : None
Optional Deps : None
Required By : pulseaudio-alsa
Optional For : firefox fluidsynth phonon-qt4 phonon-qt5
speech-dispatcher Conflicts With : dummy
Replaces : None
Installed Size : 4.00 KiB
Packager : Unknown Packager
Build Date : Sun 18 Aug 2013 06:06:40 PM CEST
Install Date : Tue 25 Apr 2017 02:41:25 AM CEST
Install Reason : Explicitly installed
Install Script : No
Validated By : None
David Runge
2017-08-14 09:32:59 UTC
Permalink
Raw Message
Hi Ralf,
Post by Ralf Mardorf
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
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
mpan
2017-08-14 12:03:45 UTC
Permalink
Raw Message
Post by Ralf Mardorf
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.
Ralf Mardorf
2017-08-14 12:48:42 UTC
Permalink
Raw Message
Post by mpan
Post by Ralf Mardorf
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_unsupported

[2]
[***@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
mpan
2017-08-14 13:03:01 UTC
Permalink
Raw Message
Post by Ralf Mardorf
Post by mpan
Post by Ralf Mardorf
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.
Ralf Mardorf
2017-08-14 13:19:11 UTC
Permalink
Raw Message
Post by mpan
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.
Eli Schwartz
2017-08-14 14:16:32 UTC
Permalink
Raw Message
Post by Ralf Mardorf
Post by mpan
Post by Ralf Mardorf
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
Paul Gideon Dann via arch-general
2017-08-15 07:47:53 UTC
Permalink
Raw Message
Post by Ralf Mardorf
Post by mpan
Post by Ralf Mardorf
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
Eli Schwartz
2017-08-15 11:45:53 UTC
Permalink
Raw Message
Post by Paul Gideon Dann via arch-general
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
Henrik Danielsson via arch-general
2017-08-15 12:14:34 UTC
Permalink
Raw Message
Post by Paul Gideon Dann via arch-general
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
Ralf Mardorf
2017-08-15 13:03:22 UTC
Permalink
Raw Message
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.
Eli Schwartz
2017-08-15 13:32:07 UTC
Permalink
Raw Message
I have no patience for reading people's broken quoting. Please try
again, this time using a decent email client.
Martin Kühne via arch-general
2017-08-15 17:59:05 UTC
Permalink
Raw Message
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
Henrik Danielsson via arch-general
2017-08-15 18:58:17 UTC
Permalink
Raw Message
Post by 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. ;)
Eli Schwartz
2017-08-15 19:10:58 UTC
Permalink
Raw Message
Post by Henrik Danielsson via arch-general
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
Henrik Danielsson via arch-general
2017-08-15 19:27:23 UTC
Permalink
Raw Message
Post by 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
the web interface.
Just to be sure, I checked my original message in Thunderbird as well
and I think it's still fairly readable. It's actually very close to
what all quotes on this list looks like in Gmail so maybe it's just
that I'm used to it.
Giancarlo Razzolini
2017-08-15 19:27:30 UTC
Permalink
Raw Message
Post by Henrik Danielsson via arch-general
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.
Post by Henrik Danielsson via arch-general
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.
Post by Henrik Danielsson via arch-general
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

Loading...