You are not logged in.

#1 2020-12-28 20:15:14

esuhl
Member
From: UK
Registered: 2009-09-16
Posts: 140

Broken orphaned AUR package. Seems trivial -- can I fix it?

I currently have the acpi-eeepc-generic package v1.0.2-3 installed.  An update (v1.0.2-4) was released some time ago, but I've been unable to install it as it requires the xorg-apps package which no longer exists (having been broken down into multiple individual xorg app packages).

The acpi-eeepc-generic package has been orphaned, so I'm wondering what to do next...  I can think of several options, but I'm not sure which (if any) would be "best practise" and avoid future issues...  I'd love to have an expert opinion! :-)

N.B. I'm actually using the package on an Arch32 machine, but, as it's in the main Arch AUR, and the "best" method to fix it should be identical between Arch and Arch32, I hope it's okay to ask this question here.

------

1.  I could ignore the updated version.
The changelog shows that the only difference in the new update was to remove xorg-server-utils as a dependency in the PKGBUILD and add xorg-apps (and an optional KDE dependency I don't care about).  So it seems the update only exists to fix dependency issues, which now exist in the new version as well.

2.  I could uninstall the package and live without it.
Unfortunately, that would break useful functions (soft-key brightness controls, enabling/disabling wifi, volume controls).

3.  I could modify the PKGBUILD, removing xorg-apps as a dependency.
But, I'd worry about subsequently removing individual xorg apps packages, not realising they are required dependencies.

4.  I could modify the PKGBUILD, replacing the xorg-apps dependency with the individual packages that replaced xorg-apps.
However, xorg-luit conflicts with luit, which I have installed as a dependency for xterm.  I can't imagine that acpi-eeepc-generic would require either luit packages, so... perhaps I should not include it as a dependency?  Or I could reluctantly uninstall xterm and use a different X terminal emulator.

5.  I could create a dummy xorg-apps package to satisfy the dependency.
I've not done this before, but the thread below makes me think it might work:
https://bbs.archlinux.org/viewtopic.php?id=238210

6.  I could examine the source code and...???
I have VERY minimal coding skills, but if I knew what I was looking for, perhaps I could figure out what to look for to identify the dependencies required...?


----

I'd be really chuffed if I could fix this problem and contribute a working PKGBUILD to the AUR for others to use. :-)

Offline

#2 2020-12-28 20:44:34

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Broken orphaned AUR package. Seems trivial -- can I fix it?

It's fine to contribute to the AUR even if you use archlinux32, as long as you make a good faith attempt to ensure it works on the officially supported x86_64 arch=() -- and a simple dependency change certainly qualifies, in fact anything that compiles on i686 should compile on x86_64 even without explicitly testing unless it e.g. uses asm but doesn't include x86_64 versions...

And in this case it's an -any package. tongue

...

I'd say the best solution here is for you to adopt it, check the scripts to see which xorg apps are actually being used, and explicitly depend on those.

Note that "xorg-luit" does not exist -- it was renamed to "luit" (technically the former is dead, and the latter is a maintained fork doing the same thing). big_smile

Last edited by eschwartz (2020-12-28 20:47:25)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#3 2020-12-30 00:47:45

esuhl
Member
From: UK
Registered: 2009-09-16
Posts: 140

Re: Broken orphaned AUR package. Seems trivial -- can I fix it?

eschwartz wrote:

It's fine to contribute to the AUR even if you use archlinux32, as long as you make a good faith attempt to ensure it works on the officially supported x86_64 arch=() -- and a simple dependency change certainly qualifies, in fact anything that compiles on i686 should compile on x86_64 even without explicitly testing unless it e.g. uses asm but doesn't include x86_64 versions...

And in this case it's an -any package. tongue

Excellent!  I'll make every possible attempt to do things the right (Arch) way.  :-) I use 64-bit Arch on my main PC so I can test builds on that if necessary.

...

eschwartz wrote:

I'd say the best solution here is for you to adopt it, check the scripts to see which xorg apps are actually being used, and explicitly depend on those.

Oh, wow...  I assumed the scripts would be big and scary... but... I had a look, and they seem really straightforward. :-o  This is looking to be easier than I thought!

I might be back with some more questions (especially before I dare upload anything to AUR!), but I think I know what I'm doing for now!

Thanks for pointing me in the right direction! :-D

Offline

Board footer

Powered by FluxBB