Package Details: pi-hole-ftl 5.25.2-2

Git Clone URL: https://aur.archlinux.org/pi-hole-ftl.git (read-only, click to copy)
Package Base: pi-hole-ftl
Description: The Pi-hole FTL engine
Upstream URL: https://github.com/pi-hole/FTL
Licenses: EUPL-1.2
Conflicts: dnsmasq
Provides: dnsmasq
Submitter: max.bra
Maintainer: max.bra (graysky)
Last Packager: max.bra
Votes: 56
Popularity: 1.50
First Submitted: 2017-05-07 15:23 (UTC)
Last Updated: 2024-08-10 09:53 (UTC)

Required by (65)

Sources (6)

Pinned Comments

max.bra commented on 2018-02-09 16:46 (UTC) (edited on 2019-10-18 23:13 (UTC) by max.bra)

ArchLinux Pi-hole is not officially supported by Pi-hole project. In case of bugs and malfunctions please DO NOT file a report upstream.

First of all check if the wiki (https://wiki.archlinux.org/index.php/Pi-hole) can help then ask here for assistance and tips.
When it will be excluded that the problem does not depend on ArchLinux we will file a bug upstream.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 .. 44 Next › Last »

Taijian commented on 2023-12-19 16:23 (UTC) (edited on 2023-12-19 16:25 (UTC) by Taijian)

@rekman: Please try to be nice to your AUR maintainers - they provide a valuable service to the community free of charge.

On the merits: This package does objectively conflict with dnsmasq in that you cannot let them both run at the same time and expect to have a good time. And it does provide enough of the fuctionality of dnsmasq that most software that requires dnsmasq will run fine. To me, that's what these PKGBUILD tags are about - and to the vast majority of users, they work fine. Otherwise more of us would have complained long ago.

If pihole-ftl does not provide what you need, feel free to edit the PKGBUILD to suit your needs. That's allowed, you know.

max.bra commented on 2023-12-19 16:21 (UTC)

ok, I see you're taking it personally, I'll stop and hang up

rekman commented on 2023-12-19 16:15 (UTC) (edited on 2023-12-19 16:15 (UTC) by rekman)

Given that you can't follow everyone's requests, you should follow the one that is objectively correct, i.e., mine. I'm sorry but whether pihole-ftl exposes the same features as dnsmasq is not something to be decided by democratic vote; it's easily checked by just calling both programs with --help that it does not. And "this non-equivalent program should have provides= and pollute /usr/bin/ with a symlink` is not a valid request.

If you read dnsmasq(8) for dhcp-host and dhcp-range you'll see that what you posted is not supported. (I should not have to tell the maintainer to RTFM, btw.) If you want to claim an interface prefix is supported, but just undocumented, feel free to point me to where in the source code it is parsed. In fact, the interface: parameter to dhcp-range was removed from dnsmasq in 2017.

max.bra commented on 2023-12-19 15:53 (UTC) (edited on 2023-12-19 15:57 (UTC) by max.bra)

given that I can't follow everyone's requests, as in a beautiful democracy, come all you to an agreement and let's settle things accordingly.

however, it is possible to configure N interfaces differently by placing the name of the interface in front of each parameter in one single conf file. for example:

dhcp-host=eth0,00:22:43:4b:18:43,192.168.0.7
dhcp-host=wlan0,00:22:43:4b:18:43,192.168.1.7

but it also works for dhcp-range for example, and others. no need for command line parameters, maybe this is why upstream has not mapped all parameters in FTL...

rekman commented on 2023-12-18 23:11 (UTC) (edited on 2023-12-18 23:12 (UTC) by rekman)

Well, if someone thinks this is a replacement they are wrong, but they can symlink it on their own. If someone, like me, thinks it is not a replacement, they are correct. That includes upstream! If a downstream user needs a symlink, they can easily provide it themself. If a downstream user, like me, needs there to not be a symlink, they can, like I have done, fork the PKGBUILD -- but this is more involved.

FTL launches a forked version of dnsmasq. The command pihole-ftl is not a replacement for the command dnsmasq; the former discards most (if not all) command line options described in dnsmasq(8). In particular, as per my previous comment, FTL ignores --conf-file= and instead reads configuration, hardcoded, from /etc/dnsmasq.conf. One result is if FTL is running on (say) interface eth0, you cannot run a separate dnsmasq instance on interface wlan0 by running something like pihole-ftl --conf-file=/etc/dnsmasq@wlan0.conf.

The question is not whether FTL contains all the features of dnsmasq but whether these are exposed in its command-line interface.

max.bra commented on 2023-12-18 08:14 (UTC)

Hi reknan, the problem is that someone think this is a replacement and ask for the symlink (or need it), some else not. Upstream declare ftl IS a replacement and so you should talk about this with them. The only thing we can do is place or remove a symlink, nothing else, but, again, someone wants it, someone not...

Anyway, ftl launch a nested ram perfect copy of a forked (for stability) version of dnsmask... How could it be different from an official ones?

rekman commented on 2023-12-17 23:55 (UTC)

This package symlinks /usr/bin/dnsmasq to /usr/bin/pihole-ftl and consequently has conflicts=dnsmasq and provides=dnsmasq. However, it does not actually provide dnsmasq in the sense of a drop-in replacement. Just compare dnsmasq --help and pihole-ftl --help; these binaries do not provide the same functionality. As a concrete difference, pihole-ftl ignores --conf-file and always reads /etc/dnsmasq.conf. So the pihole-ftl binary cannot be used to run multiple instances of dnsmasq on the same machine, but dnsmasq can. pihole-ftl contains a fork of dnsmasq and exposes some but not all of its functionality; it is not a replacement.

max.bra commented on 2023-02-27 11:40 (UTC)

@loathingkernel done w/o rel bump. cleaner. i like it. opinions are welcome.

max.bra commented on 2023-02-24 12:16 (UTC)

I take advantage of the request to fix this: I always hated the date solution inserted some time ago following another request.
I think I will also implement the release number in github patch name.

loathingkernel commented on 2023-02-24 11:30 (UTC) (edited on 2023-02-24 11:33 (UTC) by loathingkernel)

I don't know how you would like to handle it, but one solution would be to statically include the patch file with the PKGBUILD. Another one would be to host a fork in github and pull the patch's commit by its url https://github.com/<user>/<repo>/commit/<sha>.patch

Edit: from a quick look, since the patch is already versioned, I don't see the need to append the date too. Unless I am missing something, wouldn't it be easier to just omit the date altogether?

« First ‹ Previous 1 2 3 4 5 6 7 8 .. 44 Next › Last »