[owfs] missing the python module

[Achrn]

Hi I'm new to archlinux, pacman etc. but I've read what I can find, and think I understood some of it. However, I'm not sure if this is a bug report or feature request or what, so would appreciate advice about how to file it and where:

When I install it on a RaspberryPi, the owfs package includes the perl language module, but not the python module. I've verified this (apart from the fact that my python code using import ow does not work) by checking the file list (pacman -Ql owfs) and there's no mention of python.

Since python is supposedly the default / preferred / encouraged programming language for the RasPi, it would be preferred (I think) if the package did include the language module (at least on this hardware).

If I get the PKGBUILD from AUR and makepkg on my in-use RasPi, it builds a package that does include the python module.

If, however, I do a completely fresh install (download from raspberrypi.org; pacman -Sy; pacman -Su; pacman -S base-devel) and then build from exactly the same PKGBUILD, the package I end up with does not have the python module.

So, what I think is happening is that because the PKGBUILD does not list python as a requisite, it is being built on a machine without python, and even though the configure options include --with-python, when configure can't find python it's not building that language module.

A fix seems to be simply to add 'python2' to the depends= directive in the PKGBUILD. If I take the same fresh install and add pacman -S python2 before I run makepkg I get an owfs package that includes the python module.

How should this be handled? The current owfs package works for the executables and the perl language module, but not for python. Python2 could be added as a requisite, in which case you'd get the python module (which I want, but someone without python probably doesn't) in the package. You could create a PKGBUILD for owfs-with-python, but in owfs there's also a php module and a tcl module, so you'd need a owfs-with-php and owfs-with-php-and-python and so on - 16 different modules to cover every combination.

My view is that python should be included, because of its special status on RasPi. The current package does include the perl module, and that's not actually necessary to owfs itself. The PKGBUILD file acknowledges this where it defines swig as a requisite.

[WarheadsSE]

AUR : https://aur.archlinux.org/packages/ow/owfs/PKGBUILD
ours: https://github.com/archlinuxarm/PKGBUIL ... s/PKGBUILD

I see nothing damningly different. Although it has been updated to p20

[Achrn]

Sorry, I don't understand the significance of your comment.

I don't think there is any significant difference between those two PKGBUILDs. I believe they will both fail to build the python module if built on a machine without python (though I haven't tested both equally as extensively - I've used the AUR one more).

Are you saying it's policy (or practice) not to deviate an ArchLinuxARM PKGBUILD from an ArchLinux PKGBUILD? In that case, presumably I have to get the ArchLinux one changed, and that will propagate into the ALARM system?

[WarheadsSE]

Your assessment is quite close. It is policy to not deviate unless necessary. As this is an AUR package, you are best to c0ntact the maintainer and notify them of the odd behavior so that they may correct it.

[Achrn]

I've started on that course of action, but actually I don't think it's quite applicable to this situation.

As I understand it, the AUR is a collection which will always be built on the specific target machine - it's just build instructions, so if you want to use an AUR package you always compile it yourself. That is, in AL, if you want owfs you get the PKGBUILD and compile it. This works fine, because if your machine has python on it, you end up with an owfs that has the python module, and if it doesn't, teh compile still works and you don't have a language module you have no use for.

However, in ALARM, owfs is a package in the repository. That is, by default, it is already compiled. However, it has apparently been compiled on a machine without python so does not have the python module. (As an aside, perl is part of base, and was presumably on the compiling machine - the package has the perl module.)

It probably isn't appropriate to put python2 in as a requisite in the AL AUR PKGBUILD, because if you don't have python on your machine, you wouldn't have a use for the module, and wouldn't want to be obliged to install python just to get owfs to compile so you can use the other bits of it.

Is there a 'standard' way of tackling these differing uses of the PKGBUILD? That is, that the existing one is fine (indeed, better than my proposed 'fix') for a compile-on-the-users-machine paradigm, but deficient (as always, IMO) as a build recipe for a ready-compiled-package paradigm (especially given the semi-special status of python on pi).

[kmihelich]

We provide precompiled packages from the AUR that are highly requested or just generally useful so that users don't have to compile them on usually slow or limited hardware. All builds take place in a clean chroot starting with only base and base-devel, which does not include python. The package needs to specify anything extra like that. These are our standards because they are in fact the correct way to do things. If this is a problem for you, rebuild the package yourself or inform the upstream maintainer of the issue.

[Achrn]

I think you're saying that there policy of not altering a PKGBUILD from the ArmLinux PKGBUILD holds even though ArmLinux and ALARM use the PKGBUILD for different purposes (in one case distributing for local compilation and in the other compiling for distribution as binary) and in this case therefore have differing requirements.

I think it is correct that the ArmLinux PKGBUILD should not mandate python as a requisite - the package builds into a usable set of binaries without it, yet anyone using the AUR will get a python module if they have use for it. So it isn't a case of 'fixing' the upstream stuff - the upstream stuff is correct for the use case upstream, just not for the use to which ALARM puts the file.

It is trivial to fix it for ALARM, but that fix would break it for ArchLinux, so I don't expect the ArchLinux package maintainer will do so (certainly, it is my view that they shouldn't).

The alternative is adding one word to the ALARM PKGBUILD, but then it would differ from the ArchLinux PKGBUILD, and that is apparently against policy (but I haven't understood whether that's dejure or defacto policy). This is the point I don't understand why yet - the PKGBUILDS are different (different version) so there isn't an automatic propagation going on, so I'm not yet understanding why they can't be more different and thereby provide a more usable package in the ALARM use case.

In trying to apply one configuration file to two usage paradigms, it doesn't work as well as it could.

[kmihelich]

The package versions are different because, yes, there isn't automatic propagation. In almost all instances it's myself updating them when I have time.

I'm not arguing semantics with you or screw around based on one word in the PKGBUILD. If the upstream maintainer wants to include python as a build dependency, it can be added to the PKGBUILD. Otherwise, I'm not going to change ours because that means I have to put more effort into updating it later, by being sure to carry forward the change. I don't care at all how you build packages locally, and by all means rebuild this one so you get what you want. In terms of distributing the packages in our repositories, everything builds the exact same way under clean chroot circumstances, with absolutely zero exceptions.

If this continues to be a problem, ***** it, I'll just delete them from our repositories and put your email address as a contact for complaints.

[Achrn]

I'm not trying to argue semantics or propose an exception to a policy for building packages, I'm trying to understand what the policies and processes regarding package building is, so I know what the right way to approach fixing the 'problem' (if it exists) is.

It might be unsolvable, because of the fundamental issue that ArchLinux and ALARM do subtly different things with (effectively) the same PKGBUILD file, and the way owfs compiles gives you different results for those different uses.

If it is policy not to deviate from ArchLinux PKGBUILD files, then probably the answer is just that the packaged owfs will not be useful to anyone planning to use python (or php, or tcl), because it doesn't build fully unless the machine compiling it has the same set of languages as the machine where it is going to be used. That's not a problem for the AUR because that's how it operates by default, but it doesn't work for precompiling packages.

As I said, I'm trying to understand the systems / processes, so I can see if there's a way of getting a fully functional owfs package in the repositories. I'm certainly not proposing that you change the systems or processes just to accommodate me or this package.

[kmihelich]

The process is simply this:

If you build a package on your machine, against everything you have installed, the package will likely pick up other stuff to enable and build with (ie, python with owfs). This is fine for you, because it's running on your machine where you already installed python and whatever else it dragged in.

Now let's say I build I build a package, going against everything sane for building redistributed Arch packages, and don't use a clean chroot that has other crap aside from what is explicitly specified as depends installed. Now someone else installs the package and binary X won't run because it can't find libY.so, because I didn't include a depend to the package libY. Now that user is pissy because he/she has to track down what library or libraries are missing, where to get them from, and hopefully just installing those extra packages will fix it.

Just because an AUR package happens to drag in some other feature because you have some other package installed does not , by no stretch of the imagination, automatically mean that is how it was intended by the package author, nor can you assume that some mysterious list of undefined packages will be installed in a system when a package is built because "that's how it should be." If that's how it should be, the PKGBUILD should explicitly define it that way. There is no excuse otherwise except for ignorance and incompetence.

In short, get the upstream maintainer to adjust the PKGBUILD, or build it yourself.