Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)

Baptiste Jonglez
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


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)

arch dev mailing list
On Wed, 14 Feb 2018 00:56:33 +0100
Baptiste Jonglez <[hidden email]> wrote:

> 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 saw the direct emails before this one, so I'll just quote part of my reply
here:

Replaces is for when packages are renamed, nothing more. That is NOT in any way
what happened here, libxfont and libxfont2 are different libraries. Should GTK3
replace GTK2? Qt5 replace Qt4?

attachment0 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)

arch dev mailing list
In reply to this post by Baptiste Jonglez
On 02/13/2018 06:56 PM, Baptiste Jonglez wrote:
> 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].
>
> [...]
>
> [1] https://bugs.archlinux.org/task/57495

Is there a reason you took a private disagreement to the public mailing
lists:

- regarding which you have confused me for the primary person
  disagreeing with you
- when in fact there are three people who directly disagree with you on
  that very issue, as I told you in that private discussion
- regarding which this public post seems to essentially exist in order
  to, I dunno, shame me into responding in view of the world at large,
  again despite my not being the only or indeed the primary person who
  you are actually disagreeing with?

I would like to register my formal objection to your treating this as a
personal disagreement between the two of us. I explained why this was
not an "Eli Schwartz thinks so" thing in that private email -- you
disliked my explanation and asked for more proof, while *simultanously*
CC'ing arch-dev-public with claims about how I "and possibly others"
disagree with you.

You did not give me a chance to respond to your new question before
CC'ing arch-dev-public.

--
Eli Schwartz
Bug Wrangler and Trusted User


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)

arch dev mailing list
> Eli Schwartz via arch-dev-public <[hidden email]> hat am 14. Februar 2018 um 01:48 geschrieben:
>
>
> On 02/13/2018 06:56 PM, Baptiste Jonglez wrote:
> > 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].
> >
> > [...]
> >
> > [1] https://bugs.archlinux.org/task/57495
>
> Is there a reason you took a private disagreement to the public mailing
> lists:
>
So, uh, how often does this happen that we need to make a big fuss on the matter? The last manual intervention was nearly a year ago with ca-certificates-utils. If anything we should argue why there was no news post on archlinux.org

Alad
Reply | Threaded
Open this post in threaded view
|

Re: Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)

arch dev mailing list
On Wed, 14 Feb 2018 02:52:16 +0100 (CET)
Alad Wenter via arch-dev-public <[hidden email]> wrote:

> > Eli Schwartz via arch-dev-public <[hidden email]> hat am 14. Februar 2018 um 01:48 geschrieben:
> >
> >
> > On 02/13/2018 06:56 PM, Baptiste Jonglez wrote:  
> > > 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].
> > >
> > > [...]
> > >
> > > [1] https://bugs.archlinux.org/task/57495 
> >
> > Is there a reason you took a private disagreement to the public mailing
> > lists:
> >  
> So, uh, how often does this happen that we need to make a big fuss on the matter? The last manual intervention was nearly a year ago with ca-certificates-utils. If anything we should argue why there was no news post on archlinux.org
>
> Alad

A news post for something completely routine? Has Arch become so boring that
people don't know how to deal with the simplest conflict?
Reply | Threaded
Open this post in threaded view
|

Re: Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)

Baptiste Jonglez
In reply to this post by arch dev mailing list
On 13-02-18, Eli Schwartz via arch-dev-public wrote:

> On 02/13/2018 06:56 PM, Baptiste Jonglez wrote:
> > 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].
> >
> > [...]
> >
> > [1] https://bugs.archlinux.org/task/57495
>
> Is there a reason you took a private disagreement to the public mailing
> lists:
>
> - regarding which you have confused me for the primary person
>   disagreeing with you
> - when in fact there are three people who directly disagree with you on
>   that very issue, as I told you in that private discussion
> - regarding which this public post seems to essentially exist in order
>   to, I dunno, shame me into responding in view of the world at large,
>   again despite my not being the only or indeed the primary person who
>   you are actually disagreeing with?
I'm sorry if you feel offended, but I'm not sure what I am shaming you
into exactly.

- I initially thought I had a disagreement with you, because you were the
  one I saw closing bug reports about the issue.  This is why I emailed
  you directly.

- your answer made it clear that we *do* disagree, but you also said that
  your position is shared with other members of the community: what you
  called "a longstanding tradition of not considering these type of issues
  to be valid bugs", and the fact that Doug and arojas also closed bug
  reports about the issue.

- so, I decided to start a public discussion about the issue, with the
  starting point that we *do* indeed disagree about it.

Quite frankly, the packaging issue itself is minor, I was just surprised
of the way it was handled: spending time to close several bug reports
about the issue and telling people that they are stupid [2], instead of just
fixing the issue in the first place.  It goes against (my idea of) common
sense.

Now, the point of this email on arch-dev-public was to discuss the
packaging issue and whether it is a policy *not* to fix these kind of
issues.  I'm fine either way, I'll know for next time.

Baptiste

[2] https://bugs.archlinux.org/task/57393#comment166572

> I would like to register my formal objection to your treating this as a
> personal disagreement between the two of us. I explained why this was
> not an "Eli Schwartz thinks so" thing in that private email -- you
> disliked my explanation and asked for more proof, while *simultanously*
> CC'ing arch-dev-public with claims about how I "and possibly others"
> disagree with you.
>
> You did not give me a chance to respond to your new question before
> CC'ing arch-dev-public.




signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)

arch dev mailing list
> Baptiste Jonglez <[hidden email]> hat am 14. Februar 2018 um 10:19 geschrieben:
>
> Quite frankly, the packaging issue itself is minor, I was just surprised
> of the way it was handled: spending time to close several bug reports
> about the issue and telling people that they are stupid [2], instead of just
> fixing the issue in the first place.  It goes against (my idea of) common
> sense.
>
I was initially surprised by the force of the reaction you linked, but then saw this was a response to the *eleventh* request. That makes it a natural response to people being relentlessly obnoxious.

About the package itself, I agree that if libxfont2 were an *actual* replacement of libxfont, then the corresponding field should be filled in. According to upstream [3], the API/ABI is however entirely different, with according .so names. As such, you'd make use of packages the rely on the old API impossible solely for a short-term convenience.

Alad
Reply | Threaded
Open this post in threaded view
|

Re: Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)

arch dev mailing list
> Alad Wenter via arch-dev-public <[hidden email]> hat am 14. Februar 2018 um 12:26 geschrieben:
>
>
> > Baptiste Jonglez <[hidden email]> hat am 14. Februar 2018 um 10:19 geschrieben:
> >
> > Quite frankly, the packaging issue itself is minor, I was just surprised
> > of the way it was handled: spending time to close several bug reports
> > about the issue and telling people that they are stupid [2], instead of just
> > fixing the issue in the first place.  It goes against (my idea of) common
> > sense.
> >
> I was initially surprised by the force of the reaction you linked, but then saw this was a response to the *eleventh* request. That makes it a natural response to people being relentlessly obnoxious.
>
> About the package itself, I agree that if libxfont2 were an *actual* replacement of libxfont, then the corresponding field should be filled in. According to upstream [3], the API/ABI is however entirely different, with according .so names. As such, you'd make use of packages the rely on the old API impossible solely for a short-term convenience.
>
And I forgot the link again:

[3] https://lists.x.org/archives/xorg-announce/2015-December/002661.html
> Alad
Reply | Threaded
Open this post in threaded view
|

Re: Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)

arch dev mailing list
Just because I had to look up the details of this....


- xorgproto replaces a lot of packages, including fontsproto:
 :: Replace fontsproto with extra/xorgproto? [Y/n]

- libxfont requires fontsproto, so this causes the following:
 :: libxfont: removing fontsproto breaks dependency 'fontsproto>=2.1.3'


- people with systems older than 2016-11-16, may have libxfont as
xorg-server depended on it until that time.  Now xorg-server depends on
libxfont2.

- libxfont2 does not replace libxfont, as it is a completely different API.

- libxfont was removed from the Arch repos somewhere in April or May
2017.  So nothing official depends on libxfont.


I don't think it is unreasonable to expect people to run "pacman -Qi
libxfont", see it was installed as a dependency and no package depends
on it and remove it.  There also does not seem to be a correct way of us
to handle this - joys of rolling release!


Funny thing...  people using yaourt probably removed this package as I
believe it highlights dependencies that are no longer needed after an
upgrade!

A
Reply | Threaded
Open this post in threaded view
|

Re: Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)

arch dev mailing list
On 14.02.2018 12:55, Allan McRae via arch-dev-public wrote:
> Funny thing...  people using yaourt probably removed this package as I
> believe it highlights dependencies that are no longer needed after an
> upgrade!

How about having this feature in pacman, maybe with an indicator if the
package is still in a repository?

Florian


signature.asc (875 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)

arch dev mailing list
On 14/02/18 22:28, Florian Pritz via arch-dev-public wrote:
> How about having this feature in pacman, maybe with an indicator if the
> package is still in a repository?

pacman -Qtd
Reply | Threaded
Open this post in threaded view
|

Re: Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)

Baptiste Jonglez
In reply to this post by arch dev mailing list
On 14-02-18, Allan McRae via arch-dev-public wrote:

> Just because I had to look up the details of this....
>
>
> - xorgproto replaces a lot of packages, including fontsproto:
>  :: Replace fontsproto with extra/xorgproto? [Y/n]
>
> - libxfont requires fontsproto, so this causes the following:
>  :: libxfont: removing fontsproto breaks dependency 'fontsproto>=2.1.3'
>
>
> - people with systems older than 2016-11-16, may have libxfont as
> xorg-server depended on it until that time.  Now xorg-server depends on
> libxfont2.
>
> - libxfont2 does not replace libxfont, as it is a completely different API.
>
> - libxfont was removed from the Arch repos somewhere in April or May
> 2017.  So nothing official depends on libxfont.
>
>
> I don't think it is unreasonable to expect people to run "pacman -Qi
> libxfont", see it was installed as a dependency and no package depends
> on it and remove it.  There also does not seem to be a correct way of us
> to handle this - joys of rolling release!
Thanks for the detailed analysis with the dates.  I see now that using the
replaces() field in this case is technically incorrect.

I was annoyed by this issue which seemed simple to fix, and consequently
pissed off by Eli's violent and insulting reaction on the bug tracker.

I still think it is wholly inappropriate to treat people this way
(whatever the reasons, eleventh reopen request or not), but Eli, please
accept my apologies for rounding up on you based on murky assumptions.

> Funny thing...  people using yaourt probably removed this package as I
> believe it highlights dependencies that are no longer needed after an
> upgrade!

> On 14/02/18 22:28, Florian Pritz via arch-dev-public wrote:
> > How about having this feature in pacman, maybe with an indicator if the
> > package is still in a repository?
>
> pacman -Qtd

For the same list, but filtered on packages that are not in any repository
("foreign" packages):

pacman -Qtdm

signature.asc (849 bytes) Download Attachment