AUR vs Released Package

[benoliver999]

I am the maintainer of buku on the AUR.

Users have noticed that the package in the releases here does not match the package that gets created in the AUR when built from source. The main focus of the issue revolves around bukuserver.

When built from source, bukuserver is present (therefore all dependencies must be met). When using the released pre-built package, it is not.

Would you like to be added as maintainer so you can add your own PKGBUILD that is used for releases to the AUR?

[jarun]

The auto-generated packages (all flavours) are only for buku rather than bukuserver. Would adding a disclaimer in the release page make this clear?

[benoliver999]

It just depends on what you want in the AUR. We can't use the auto-generated package there, users have to rebuild every time.

So either:

• Things stay the same (buku and bukuserver included in one package)
• We split it into two AUR packages, buku and bukuserver.

[jarun]

We split it into two AUR packages, buku and bukuserver.

I think this is the best way to go.

I was thinking of another approach though. What if the generated package is renamed to buku-cli? In that case there wouldn't be a conflict.

[jarun]

@rachmadaniHaryono to explore the first option, what would it take to package bukuserver as well during auto-generation?

[benoliver999]

We split it into two AUR packages, buku and bukuserver.

I think this is the best way to go.

I was thinking of another approach though. What if the generated package is renamed to buku-cli? In that case there wouldn't be a conflict.

In terms of the AUR, this would not really change anything. The reason being that you cannot submit a pre-built package to the AUR. You can only 'build from source' so to speak.

[rachmadaniHaryono]

i'm still not quite understand the solution and aur package problem.

but if you want a single folder for buku and bukuserver possible solution i can think of is this

• move buku to buku/__init__.py: this hopefully minimize import error if other package is using this
• move bukuserver content to buku folder: there will be no bukuserver module but i don't think anyone use that. acess to bukuserver will be explained below
• change entry point of buku and bukuserver: because everything is moved to buku folder, we also change then entry point
• change manifest file: just because we move some file from bukuserver folder

but i don't know if this is viable with debian package. see #307

[jarun]

@benoliver999

The reason being that you cannot submit a pre-built package to the AUR

I think we are talking on 2 different things here.

The auto-generated package has nothing to do with the AUR package. The auto-generated package is just there for having a quick test of buku engine (and NOT the server). Users who are on Arch should use the PKGBUILD from AUR. Where is the conflict?

My earlier understanding was - someone installing buku from the auto-generated package is trying to use PKGBUILD from AUR and there is a conflict. Is that the problem? If it is, we can just figure out a way to state that this auto-generated package has nothing to do with AUR.

Do you see any other issue here?

[benoliver999]

Ah sorry no - I wan't very clear!

The issue is simply that some users have noticed that bukuserver is included in the AUR build, but not in the auto-generated one. They are saying that therefore we should not include bukuserver, because you are not doing so in the auto-generated one.

If you are happy with the AUR PKGBUILD as it stands, we should leave it that way.

[jarun]

you are not doing so in the auto-generated one.

Right, that's why I wanted to rename the auto-generated package to buku-cli and add the note in the README clearly stating that the auto-generated package doesn't have the server component.

If you are happy with the AUR PKGBUILD as it stands

I am more than happy with it and the commendable effort you guys put into bringing state-of the art software to users. Thank you!

[benoliver999]

Got it, and thank you for your time! buku is awesome!

[jarun]

I have made the required changes in commit 8e5357e.

[benoliver999]

Just FYI - I have since had a couple of emails asking the AUR to be split. It is more like the 'arch way', so I have done it.

buku is now CLI only.

bukuserver installs both.

[jarun]

Awesome! Thank you!

[cinghiopinghio]

dear @benoliver999,
I just updated from AUR and noticed that buku is not accessible as a python module anymore (and I was relying on this for my daily work).
All the following files disappeared from my machine with 4.2.2-4:

/usr/lib/python3.7/site-packages/bukuserver
/usr/lib/python3.7/site-packages/buku.py
/usr/lib/python3.7/site-packages/buku-4.2.2-py3.7.egg-info
/usr/lib/python3.7/site-packages/__pycache__/buku.cpython-37.pyc
/usr/lib/python3.7/site-packages/bukuserver/templates/bukuserver

Is this meant to stay as is? Should I install bukuserver instead?

[jarun]

My expectation is - package buku installs the cli and package bukuserver installs both cli and server.

[benoliver999]

This is correct. As for using it as a python module, I would install bukuserver.

This is because to build bukuserver we run setup.py, but to build buku alone we just do

make DESTDIR="${pkgdir}" PREFIX=/usr install

Which doesn't install it as a python package I don't think.