OpenRC & eudev on Arch

aaditya · 2014-06-07 07:29:51

x33a wrote:

@ aaditya, artoo should finally be happy now

x33a, between the two of us, we seem to have covered both use cases

Btw artoo's package worked out of the box for me with minimum fuss.

artoo · 2014-06-10 23:08:10

@ apg

I would offer maintaining openrc if you don't have time.
It should be possible to upgrade your version to my one.
Its just an offer, but it would simplify things on AUR.

Lone_Wolf · 2014-06-11 12:18:35

Artoo, i haven't seen apg openrc packages users complain.

Also he did add the rpcbind init-files stuff.

The number of service files in apg packages is much lower then those in yours, but that's not the same as being outdated.

Basically it seems you want to provide a complete openrc pacakge set, while apg focuses on what's needed for him and users of his packages specifically.

artoo · 2014-06-11 12:37:15

I saw the comment on AUR on services pkg and thought I ask, since this was a complaint.

My version effictively provides less than a single services pkg btw, its choice of user to install what he needs.

Last edited by artoo (2014-06-11 12:47:12)

Lone_Wolf · 2014-06-11 12:49:24

artoo wrote:

What stuff isn't necessarily needed in my script packages? They match the runscript depends.

as an example, i looked at ntp service in your packages.

$ makepkg --pkg ntp-openrc
==> Making package: openrc-misc 20140530-1 (wo jun 11 14:17:41 CEST 2014)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Missing dependencies:
  -> connman
  -> dbus-openrc
  -> fcron
  -> haveged
  -> lirc-utils
  -> metalog
  -> openrc-base
  -> rsyslog
  -> sane
==> ERROR: Could not resolve all dependencies.

makedepends=('connman'
	    'cpupower'
	    'cups'
	    'dbus-openrc'
	    'fcron'
	    'fuse'
	    'haveged'
	    'lirc-utils'
	    'lm_sensors'
	    'metalog'
	    'ntp'
	    'openrc-base'
	    'rsyslog'
	    'sane'
	    'syslog-ng')

please explain why a ntp service needs things like connman, lircutils and sane, lm_sensors , cpupower, fuse to build ?
Why are all those loggers needed at buildtime ?

If you need to have all loggers at buildtime, why is fcron the only cron ?
Does your openrc-misc scripts work with other cron implementations like cronie and anacron ?

looking at the pkgbuild for openrc-misc, the individual packages copy files and use sed.
openrc-base is about the only makedepend i would expect, and technically even that may not be needed.

Last edited by Lone_Wolf (2014-06-11 12:50:40)

artoo · 2014-06-11 12:56:13

First, the AUR is not uptodate. I thought we already are through the nacamp advice? It was discussed couple of pages earlier, page 12.

And even if the current version demands these makedepends, the packages are all individual packages, I don't force user to install tons of script packages he doesn't need or doesn't have the true package installed for the rc service depends on.
Its a modular concept with individual dependencies according to given runscript, and apg provides a static services package, so services you can't start because you miss the depending package.

In essence, a namcap advise causes these makedepends, and until now, I followed namcap, but removed the makedepends in git repo already.
Its more possible now with pkgbuild-introspection.

Last edited by artoo (2014-06-11 13:23:30)

Lone_Wolf · 2014-06-11 13:32:05

artoo,

i agree their are changes between your way of doing things and apg's way.
My post was not meant to criticise your way of doing things, but to offer some advice on how to improve your pkgbuilds.

I have been maintaining aur packages for several years now, some of which have been moved to community.

Before i install any aur package, i look at the pkgbuild.

The openrc-misc pkgbuild (haven't looked at any other packages you maintain yet) has in my opinion several flaws.
Apart from the unnecessary makedepends, it uses a lot of internal variables.
You do use a system for their naming, but don't explain how it works.
I don't really see a way to get rid of those variables without using manual downloads, else i'd suggest it.

As for the aur package not being uptodate :
you use a git repo for your pacakges i think, where is the openrc-misc-git package for those that want the lastest version always ?

Edit :
seems i only replied partially on page 12,
namcap output should always be treated as a SUGGESTION.

Last edited by Lone_Wolf (2014-06-11 13:38:51)

artoo · 2014-06-11 13:38:39

The point of asking was, my openrc packages are now supoorted by a bigger arch based distro.
We are more than one people to maintain it, and packages are about to go into repo.

I asked to eventually synchronize AUR and repo.

But here is my git
https://github.com/udeved/pkgbuilds

Whats the problem with file vars?

Last edited by artoo (2014-06-11 13:40:49)

Lone_Wolf · 2014-06-11 13:44:51

The point of asking was, my openrc packages are now supoorted by a bigger arch based distro.
We are more than one people to maintain it, and packages are about to go into repo.

Would that be Archbang ?

Keep in mind that derivative distros are NOT arch, and it's possible changes they want/need MAY lead to incompabitilities with archlinux.

artoo · 2014-06-11 13:47:09

Lone_Wolf wrote:

The point of asking was, my openrc packages are now supoorted by a bigger arch based distro.
We are more than one people to maintain it, and packages are about to go into repo.
Would that be Archbang ?
Keep in mind that derivative distros are NOT arch, and it's possible changes they want/need MAY lead to incompabitilities with archlinux.

No, manjaro, if its ok to mention it. You would be astonished about team size of AB.
Its 100% arch compatible, use arch upstream builds.

The AUR would profit from a team developing and maintaining the builds.

The file vars aren't that complicated. I* defines init.d script version, C* defines conf.d file version.
The AUR couldn't handle arrays for that last time I tried.
Thats it, and I don't have to edit the install part in package function, just update file var eventually and do checksum.

PS: The current AUR version should make you happy, it upgrades openrc-base pkg to openrc-core.
I'll try to remove the 3 makedepends for openrc-base pkgbase so only openrc-core has them.

Last edited by artoo (2014-06-12 06:31:28)

Lone_Wolf · 2014-06-12 13:35:06

No, manjaro, if its ok to mention it. You would be astonished about team size of AB.
Its 100% arch compatible, use arch upstream builds.
The AUR would profit from a team developing and maintaining the builds.

I think it's ok to mention it, and do agree having a team working on it would be beneficial.
As long as team openrc-artoo does test things on arch installlations as well as manjaro installations i see no harm in it.
If manjaro wiki and / or forum gets dedicated parts dealing with openrc, it might even be a good idea to link to them under external links on the arch openrc wiki page.

The file vars aren't that complicated. I* defines init.d script version, C* defines conf.d file version.
The AUR couldn't handle arrays for that last time I tried.

I noticed that, but had to look at the files being downloaded to figure it out. I feel this should be documented in the PKGBUILD.

I've looked at openrc-core and openrc-misc and noticed some other things :

you move the source files to $pkgdir, then use _shebang , _runpath & _binpath to adapt them.
I think it's cleaner (and better readable) to do that in the prepare() function and just apply those changes to all source files at that time.
Doing it this way probably also means you can remove those variables.

openrc-core only
_base_args , _net_args, _rc_args :
imo using these make the pkgbuild less readable and harder to understand.

By using bash multiline option, you could make them easily changeable while making things more readable.

It would look similar to this then :

cd "${srcdir}/${_net}-${_nver}"
make \
  # base settings \
  SYSCONFDIR=/etc \
  BRANDING='Arch Linux'  \
  PREFIX=/usr \
  SBINDIR=/usr/bin \
  # network settings \
  LIBEXECDIR=/usr/lib/${_net}

cd "${srcdir}/${_name}-${pkgver}"
make \
  # base settings \
  SYSCONFDIR=/etc \
  BRANDING='Arch Linux'  \
  PREFIX=/usr \
  SBINDIR=/usr/bin \
  # rc settings \
  LIBEXECDIR=/usr/lib/rc \
  MKSELINUX=no \
  MKPAM=pam \
  MKTERMCAP=ncurses \
  MKNET=oldnet

Added

I also noticed you have special functions (_instal_udev and such) defined in the openrc-core pkgbuild, but no explanation whatsoever what they do.
While the functions are not complicated, i feel they should have a few comments explaining what they are meant to do.

offtopic : does it show i used to be a programmer 3 decades ago and failed an exam due to my code being not readable enough ?

Last edited by Lone_Wolf (2014-06-12 13:40:25)

artoo · 2014-06-12 14:12:42

Lone_Wolf wrote:

offtopic : does it show i used to be a programmer 3 decades ago and failed an exam due to my code being not readable enough ?

Yes, it does show, the part of being documentation 'obsessed'
I didn't fail exam, did some comments, and in work life, there are tools (or people) to generate documentation.
I mean hey, its a pkgbuild, build instructions, supposed to be used by people who have at least bit understanding what they do.

I find the sed part in prepare good idea, but, the source files would get edited.
If I do it in pkg function, you have original source file in /src folder, which I find is better. There is no "make sed clean".
It has practical reasons to do it in pkg function, as edited source files screw up checksums, and you'd have to download again.

As for custom functions.
One is for udev-init-scripts, one for netifrc, and one installs kmod script.
I could do them in separate packages, but its better this stuff is bundled in one build.

Concerning make var arrays, they will stay. My programmer mind demands me to use a var instead of repeating to write same lines again.

Last edited by artoo (2014-06-12 14:34:17)

Lone_Wolf · 2014-06-12 14:52:46

I find the sed part in prepare good idea, but, the source files would get edited.
If I do it in pkg function, you have original source file in /src folder, which I find is better. There is no "make sed clean".
It has practical reasons to do it in pkg function, as edited source files screw up checksums, and you'd have to download again.

prepare() is run AFTER downloading/checksumming / extracting files , and happens in $srcdir.
I'm not sure whether makepkg copies non-archive sourcefiles to $srcdir or just symlinks them.
If it symlinks them, you have a point.
if it copies them, all that's needed is cleaning the src folder.

An alternative would be to copy sourcefiles to a build folder, then apply the changes there from the build() function .

Last edited by Lone_Wolf (2014-06-12 14:53:52)

artoo · 2014-06-12 16:45:44

Lone_Wolf wrote:

I find the sed part in prepare good idea, but, the source files would get edited.
If I do it in pkg function, you have original source file in /src folder, which I find is better. There is no "make sed clean".
It has practical reasons to do it in pkg function, as edited source files screw up checksums, and you'd have to download again.
prepare() is run AFTER downloading/checksumming / extracting files , and happens in $srcdir.
I'm not sure whether makepkg copies non-archive sourcefiles to $srcdir or just symlinks them.
If it symlinks them, you have a point.
if it copies them, all that's needed is cleaning the src folder.
An alternative would be to copy sourcefiles to a build folder, then apply the changes there from the build() function .

Its symlinks, so can dfine the dirs in makepkg.conf
I set it to a centralized src dir, and they get symlinked in makepkg src folder.

The alternative takes longer than do it in pkg function. Before I copy the stuff, I let it do in pkgfunction.

Lone_Wolf · 2014-06-13 11:29:47

The alternative takes longer than do it in pkg function. Before I copy the stuff, I let it do in pkgfunction.

looking at the package functions, you use install to put them in $pkgdir then apply the changes.

About copying in build function being slower then doing it in package function :
In my opinion this is one of the cases where cleaner code is more important then performance.
It's your call and that of the team though.

artoo · 2014-06-13 11:57:38

It depends how you define clean code.
In my view, eg using a make args array is cleaner than writing down same args again.
In the end, the pkgbuild generates a package, and this is the aim.
Even if pkgbuild looks unreadable, if the built package works as intended, its fine with me.

Anyway, there appears to be a conflict between reason and AUR parser of PKGBUILDS.
According to wiki, makedepends are global, cannot be overridden in package function for split builds.
This poses a bit of conflict how to handle it.

eg eudev

eudev merged with eudev-openrc

eudev has makedepends, eudev-openrc hasn't.
I can set makedepends in eudev package function, AUR seems to accept it, but will this work in a chroot build too?

It didn't work with openrc-core when I set makedepends in package function. Aur will need to be updated, thus all packages in openrc-base will inherit makedepends.

Last edited by artoo (2014-06-13 12:02:29)

Lone_Wolf · 2014-06-13 13:33:35

it doesn't really matter if AUR accepts it, makepkg is what takes care of dependency checking.

it's a bash script, and afaict makedepends are hard linked to the build function.
The build function is run for every package function.

It IS possible to omit the build function, you could try removing it and put the makedepends in each individual package function (along with code to do the things you know do in build ).
Whether makepkg can handle makedepends in package functions can only be answered by looking at the code.

An alternative would be to use meta packages that build nothing.
check lxqt-desktop-git (AUR) or kde-meta-graphics .

artoo · 2014-06-13 13:46:29

You can put makedepends in package function, but as said, they will be ignored by makepkg if you don't have depends already installed, chroot fails to build.
I tried with eudev. I know I can ommit build function, but this is not the problem here.
makedepends in pkg function will be ignored and no gtk-doc will be installed.
Best solution would be to let makedepends be overridden in pkg function if that is possible.
This is pacman source related.

I actually don't see how metapkg will solve it? the pkgbuilds are designed for repo use with groups, not necessarily from aur.
Its been always a compromise so far to make them work with aur.

Last edited by artoo (2014-06-13 13:46:57)

apg · 2014-06-13 13:47:35

Putting makedepends inside any function is nonsensical, the entire point is to make sure they're installed *before* makepkg starts building anything.

artoo · 2014-06-13 14:03:36

Right, hence namcap complains about this and makepkg ignores "local" makedepends.
The entire system expects if split build same source, not one component with makedepends, the other without eventually.
The use case here is not a standard one for split packages.

What about maintaining openrc? If you want to maintain it further, no problem.
It'd be just cool if you said yes or no, so pkgs can go to repo, and these won't start with upgrade in case you didn't want to maintain.

Lone_Wolf · 2014-06-13 14:24:54

artoo, please clarify what you want.

There are several incompatibilities between apg & artoo implementations of openrc.
Judging from this thread, both approaches have their users and are maintained.

We even failed to make service files compatible between the 2 implementations, merging them seems unlikely to happen.

Are you looking for someone to take over AUR management for your implementation ?

artoo · 2014-06-13 14:38:15

No, I asked apg if he further wants to maintain his version.
Judging from AUR comments on his services package, it has not been updated, and still seems to have issues, as it is still v25, most likely the version of udev scripts.

I think it would b possible to upgrade from openrc --> openrc-core, services are incompatible anyway and would have to be replaced by the individual packages for openrc-core.

Why have two incompatible versions for openrc in AUR, but none in any repo?

Last edited by artoo (2014-06-13 14:39:43)

Lone_Wolf · 2014-06-13 14:59:58

Git PKGBUILDS always build latest version, and are typically only changed if they don't build anymore.
It's not unusual to see a git package that hasn't been updated in 2 years , but still builds flawlessly.

Anyone building openrc-arch-services-git will get the latest version of the scripts, currently 0.28 .

artoo · 2014-06-13 15:02:49

And how go scripts in git repo? Was the comment false on AUR?
Did I hallucinate?

Anyway, I am tired of getting no answer.
A simple yes or no would be more than sufficient, from apg.

I made a proposal, and I would consider it just good manners if there was an answer, whatever the answer may be.

Last edited by artoo (2014-06-13 15:06:41)

Lone_Wolf · 2014-06-13 15:13:32

The comment on aur did claim "Scripts are really outdated" , but didn't give any details.

I am still running the 0.25 version (i tweaked some of the scripts for my personal use, and updating means i need to redo those tweaks), and am not encountering any problems.

Arch Linux

#351 2014-06-07 07:29:51

Re: OpenRC & eudev on Arch

#352 2014-06-10 23:08:10

Re: OpenRC & eudev on Arch

#353 2014-06-11 12:18:35

Re: OpenRC & eudev on Arch

#354 2014-06-11 12:37:15

Re: OpenRC & eudev on Arch

#355 2014-06-11 12:49:24

Re: OpenRC & eudev on Arch

#356 2014-06-11 12:56:13

Re: OpenRC & eudev on Arch

#357 2014-06-11 13:32:05

Re: OpenRC & eudev on Arch

#358 2014-06-11 13:38:39

Re: OpenRC & eudev on Arch

#359 2014-06-11 13:44:51

Re: OpenRC & eudev on Arch

#360 2014-06-11 13:47:09

Re: OpenRC & eudev on Arch

#361 2014-06-12 13:35:06

Re: OpenRC & eudev on Arch

#362 2014-06-12 14:12:42

Re: OpenRC & eudev on Arch

#363 2014-06-12 14:52:46

Re: OpenRC & eudev on Arch

#364 2014-06-12 16:45:44

Re: OpenRC & eudev on Arch

#365 2014-06-13 11:29:47

Re: OpenRC & eudev on Arch

#366 2014-06-13 11:57:38

Re: OpenRC & eudev on Arch

#367 2014-06-13 13:33:35

Re: OpenRC & eudev on Arch

#368 2014-06-13 13:46:29

Re: OpenRC & eudev on Arch

#369 2014-06-13 13:47:35

Re: OpenRC & eudev on Arch

#370 2014-06-13 14:03:36

Re: OpenRC & eudev on Arch

#371 2014-06-13 14:24:54

Re: OpenRC & eudev on Arch

#372 2014-06-13 14:38:15

Re: OpenRC & eudev on Arch

#373 2014-06-13 14:59:58

Re: OpenRC & eudev on Arch

#374 2014-06-13 15:02:49

Re: OpenRC & eudev on Arch

#375 2014-06-13 15:13:32

Re: OpenRC & eudev on Arch

Board footer