search

rozniak / xfce-winxp-tc

Windows XP stuff for XFCE
Other
1.11k stars 37 forks source link

Packaging port for Arch Linux #182

Closed rozniak closed 1 year ago

rozniak commented 1 year ago

Following completion of #140 , it is viable to make an actual proper packaging port for Arch Linux.

Roughly what needs doing:

I don't think you should worry about the xfce4-panel fork, I plan on binning that off sooner rather than later.

rozniak commented 1 year ago

Unfortunately whilst I did try to have a look into this, I tried Manjaro with XFCE but it just black screens in VirtualBox and I don't feel like having to debug that just to begin looking at packaging right this second with other stuff to do. If anyone feels like tackling the above stuff in the meantime just give me a shout about any queries :+1:

SelfRef commented 1 year ago

OK, so after some tweaking I've managed to create and publish a working PKGBUILD to Arch User Repository.

The name of the package is xfce-winxp-tc-git (and there is PKGBUILD)

Some thoughts about making this package:

I wanted to reuse existing script bldnpkg.sh to define build process for Arch, unfortunately the script is already trying to make Debian packages that have no use for Arch package so I just looked at build process alone and rewrote it in PKGBUILD itself.

Most of the projects I've encountered basically use standard ./configure; make; make install trio but in case of this project there are many components that are interconnected together even at build time. That's why I've decided to not create multiple packages and make one monolithic package with all components included. I suppose the libraries/applications/themes could be easily extracted and then connected by dependency definitions so that will be my goal for next releases of the package.

There are some hacks and tweaks in my build script. First - all requirements of shared libraries are removed from CMakeLists files to allow the build to continue without these packages to be installed. Instead I've added compiler and linker flags to use appropriate headers/libraries from previously built binary components. There is also a mod that changes /usr/lib64 directory path to /usr/lib because in Arch Linux /usr/lib64 is a symlink file and cannot be used to install files to by package manager.

At last I added the components.build file that's included in AUR with PKGBUILD. This is a list of components that will be built and then added to final package. It can be altered locally to change build process easily in case someone doesn't want all components from the repository.

I tested this package script by building manually via makepkg and by yay AUR helper on my machine and all components seem to works correctly, even applications like run and notepad. I'm going to test them on my other machine with XFCE so I'll ensure that all XFCE plugins work correctly. I also wanted to create separate PKGBUILD for xfce-winxp-tc-panel but I saw it already has unpublished PKGBUILD definition so I'm not sure what should I do with that.

Final thoughts: This is my first public contribution to AUR as my previous PKGBUILD were only for my personal use so I will gladly accept criticism what can be improved.

rozniak commented 1 year ago

Thanks for having a look at this!

I wanted to reuse existing script bldnpkg.sh to define build process for Arch, unfortunately the script is already trying to make Debian packages that have no use for Arch package so I just looked at build process alone and rewrote it in PKGBUILD itself.

This is fine - my intent was to get all the compile/build steps in CMake, and then the 'last mile' for actually creating the package would be done via the script. :smiley:

Most of the projects I've encountered basically use standard ./configure; make; make install trio but in case of this project there are many components that are interconnected together even at build time.

I think what you've done is on the right track, in terms of adding linker arguments to specify a locally built version of a lib for linking so the build machine doesn't need to install the packages (important if we want automated builds). That's something that I did want to look into so this is a good start.

There is also a mod that changes /usr/lib64 directory path to /usr/lib because in Arch Linux /usr/lib64 is a symlink file and cannot be used to install files to by package manager.

I would do this in /packaging/cmake-inc/packaging/CMakeLists.txt, that file is intended to make package format specific adjustments for the build / install steps. Notice that for deb it adjusts LIB_DIR for the multi-arch dirs on Debian - I guess we could define a format like archpkg or whatever you think it should be called, and simply set(LIB_DIR lib PARENT_SCOPE)

At last I added the components.build file that's included in AUR with PKGBUILD. This is a list of components that will be built and then added to final package.

This is good - in future I have it in mind to add some 'full build' script or something with a complete component list somehow.

I tested this package script by building manually via makepkg and by yay AUR helper on my machine and all components seem to works correctly, even applications like run and notepad.

Does makepkg create packages for pacman or whatever? Just wondering if we can have a local package script option akin to the Debian one.

I also wanted to create separate PKGBUILD for xfce-winxp-tc-panel but I saw it already has unpublished PKGBUILD definition so I'm not sure what should I do with that.

I forgot about that - I think leave it for now as I plan on replacing the panel anyway so it will just become a normal component. :grin:

SelfRef commented 1 year ago

I would do this in /packaging/cmake-inc/packaging/CMakeLists.txt, that file is intended to make package format specific adjustments for the build / install steps. Notice that for deb it adjusts LIB_DIR for the multi-arch dirs on Debian - I guess we could define a format like archpkg or whatever you think it should be called, and simply set(LIB_DIR lib PARENT_SCOPE)

Cool, that will make the PKGBUILD a little simpler.

Does makepkg create packages for pacman or whatever? Just wondering if we can have a local package script option akin to the Debian one.

makepkg while executing PKGBUILD definition (it's just a very specific bash script) always do at least these 4 tasks:

  1. downloads all sources from source
  2. prepare() sources to build (patching and so)
  3. build()
  4. package() files using fakeroot which becomes a compressed .pkg.tar.zst

This is a very similar concept to classic ./configure; make; make install but there is one very crucial difference:

PKGBUILD can be just placed in the repository with source files and the only modification to make it work would be to change source variable. Although this is uncommon because the main usage of PKGBUILDs is to push them to AUR (which is just a git server for PKGBUILDs) without sources and without touching source repo so anyone can create PKGBUILD for any project and then anyone else can pull it and makepkg/yay will do everything needed to create a package (including git clone).

I don't know of any method to keep PKGBUILD in AUR synced with external repository like on GitHub but a copy of PKGBUILD (with minor changes) can be just added to this repo for packaging automation.

I'm going to split PKGBUILD to extract shared libs to remove dependency hacks and will look at separate CMakeLists.txt. When it will look final I'll create a PR with all changes :smiley:

rozniak commented 1 year ago

I might be able to have a better review of this now I have working Arch Linux VM - I should've just used plain Arch Linux in the first place since it actually works for me unlike Manjaro!

rozniak commented 1 year ago

Have completed #183 , so the xfce panel port can be dropped and replaced with shell/taskband in this repo.

SelfRef commented 1 year ago

Have completed #183 , so the xfce panel port can be dropped and replaced with shell/taskband in this repo.

The new TaskBand works really nice. Now xfce4-panel can be removed entirely from the system (or disabled).

SelfRef commented 1 year ago

@rozniak Sorry to bother you again but while discussing on AUR package page we've found the current distid.sh script does not takes into account Arch derivatives (like EndeavourOS or Manjaro) while detecting distribution.

Honestly I cannot find a good way to check that other than looking if pacman package manager is installed but if someone is using AUR it have to be on compatible distro.

That's why an additional flag to buildall.sh would be helpful to manually set target and not use distid.sh. For now I just added a workaround sed -i 's/distro_in_use=.*$/distro_in_use=arch/' distid.sh in prepare().

rozniak commented 1 year ago

I was thinking about that - the same might apply to Debian and its derivatives.

Not 100% sure what the most reliable method is, other than to basically probe to see if dpkg or pacman is available, unless there is some scenario where either of those would exist on a distro that doesn't actually use them for packaging?

SelfRef commented 1 year ago

I've checked at DistroWatch Search looking for "Based on" and "Package management". It looks like every Arch-based is using Pacman but it's probably a type of packages, just like for Debian it's DEB in every case.

Looking for solution on the Internet it looks the preferred solution is to check os-release or check existence of package manager. I'm pretty sure every derivative does keep pacman/dpkg/apt/yum at least for compatibility purposes - what sense would it have to make derivative distribution and break most of the scripts that assume a core component is there? So - probing a package manager is probably a good solution in this case.