[arch-dev-public] Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)

Baptiste Jonglez baptiste at bitsofnetworks.org
Tue Feb 13 23:56:33 UTC 2018


Hi,

Eli and I disagree about how dependency conflicts should be handled when
packaging.  This was prompted by the libxfont dependency conflict arising
from recent xorgproto changes [1].

My position in this case: it would be really easy to avoid this conflict,
by adding libxfont to the Replaces() array of xorgproto.  This would cause
libxfont to be automatically uninstalled upon sysupgrade, which is nice
because it's an obsolete and now-useless package.

I think this kind of automatic handling of dependencies and obsolete
packages is desirable whenever possible, precisely because it is *automated*.
On the contrary, with the current libxfont/xorgproto situation, every Arch
user has to spend time to *manually* fix the dependency issue (by removing
libxfont).

As packagers, I believe we have better things to do than purposefully
waste the time of Arch users.  Especially for dependency conflicts like
this one, which is so trivial and boring: libxfont should clearly be
deleted, and an Arch user will learn nothing interesting by having to
manually fix the dependency issue.

But it seems that this position is not shared by Eli (and possibly
others), who thinks that Arch users should be able to figure out this kind
of issues by themselves.  I agree, but this is not a reason to force
boring tasks on them, while we could have easily avoided the issue in the
first place.

If there are some existing rules or "traditions" that address this
question, please provide pointers.  Otherwise, I would like to know if
there is a consensus one way or the other.

Thanks,
Baptiste

[1] https://bugs.archlinux.org/task/57495

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20180214/5644e073/attachment-0001.asc>


More information about the arch-dev-public mailing list