Opened 13 years ago

Closed 12 years ago

Last modified 10 years ago

#3212 closed defect (fixed)

Avahi-0.6.28

Reported by: Randy McMurchy Owned by: blfs-book@…
Priority: high Milestone:
Component: BOOK Version: SVN
Severity: major Keywords:
Cc:

Description (last modified by Randy McMurchy)

Version increment to 0.6.28

http://avahi.org/

The 3 version increments released by the developers are "bugfix releases and fix minor security issues.

See the following additional comments for additional items that need to be addressed. Note that the description of this ticket has been changed and Bruce replied to the original description, which is now a comment following Bruce's reply.

Change History (10)

comment:1 by bdubbs@…, 13 years ago

Seems reasonable to me. I think that approach makes it easier for both the editors and the users.

comment:2 by Randy McMurchy, 13 years ago

Description: modified (diff)
Priority: normalhigh
Severity: normalmajor
Summary: Avahi initscriptsAvahi-0.6.28
Type: taskdefect

comment:3 by Randy McMurchy, 13 years ago

The Avahi package has broken initscripts for an "lfs" distro. This forces us to install a patch and then run autoreconf which "fixes?" the initscript installation process.

I am suggesting we do away with using --with-distro=lfs and instead use --with-distro=none. That way the package will not install initscripts, and we can add non-broken initscripts to our BLFS initscript package and install them like *every* other package in BLFS that uses initscripts.

comment:4 by Randy McMurchy, 13 years ago

The avahi package instructions create a user and two groups to support the running of the avahi daemon. However, using the default instructions in the book, the daemon is not built or installed. I suggest that there be a mention that only if you need the daemon do you need to create the user and groups.

Additionally, the explanation of --disable-libdaemon should be made more clear that using it means the daemon does not get built or installed. We need to identify that libdaemon must be installed, and the --disable-libdaemon parameter removed if you need the daemon to be installed.

comment:5 by willimm, 13 years ago

I'll give my opinion on this:

I'm the original author of the Avahi LFS initscripts. When I first created them, I was lazy and forgot to test before making the patch, and so, that's why the unpatched Avahi LFS initscripts are broken. The patch that I made was to fix the brokenness and allow it to build and install on LFS systems. This also includes making the symlinks to the script at install time.

I did try to submit this patch, but when I did it before, it only just resulted in a shouting match with the maintainer. I tried once more, but it got ignored. If you can convince the maintainer to integrate my Avahi initscript patch into the source, I will be really glad.

Anyway, my way of handling this is to keep patching the initscripts, add libdaemon as a recommended dep, and get my patch in to Upstream.

Of cource, you can just put the bootscripts in the blfs-bootscripts package, but they have to be my patched ones in order to work.

in reply to:  5 comment:6 by willimm, 13 years ago

Replying to willimm:

Anyway, my way of handling this is to keep patching the initscripts, add libdaemon as a recommended dep, and get my patch in to Upstream.

My bad, I forgot that libdaemon was in the book.

comment:7 by Randy McMurchy, 13 years ago

William,

I appreciate your interest in the avahi project and your willingness to provide LFS style initscripts upstream. However, you have self-admitted that upstream is not interested in any more patches, so we would have to continually update the patch (even if just a name change) and run autoreconf every time there is a version update to avahi.

The BLFS bootscripts should be maintained in a single project file so that if changes are required globally to the bootscripts (make them LSB compliant, for example), we can do it easily and ensure that all the bootscripts are touched accordingly. The last thing we want to do is to have to create a patch to an upstream project when we could (and should) be maintaining it ourselves.

All the BLFS packages that require bootscripts are included in the single blfs-bootscripts file. This is the preferred method because it is less work for the editors every time there is an avahi update, it is consistent with all BLFS packages, and we don't have to patch upstream packages.

Please, I understand you do not like this decision, however two BLFS editors have agreed that our maintaining the avahi bootscripts is the best overall solution, so at this point until something changes, let's drop the subject and move on. It would be helpful if you could provide a patch to the BLFS bootscripts themselves to include scripts for the avahi package.

comment:8 by willimm, 13 years ago

Just want to say this now:

This patch was considered by Lennart again, and he showed interest in merging the patch if I'd remove the part that creates the symlinks automatically. Because I was busy, I told Lennart that I diddn't mind if that part was removed and wanted him to merge it without that part of the patch. He asked me to prepare a clean git patch, but because I diddn't have the original patch and was strapped for time, I requested that Lennart would create a patch under my name. I diddn't get a response, and Avahi 0.6.29 was merged without my patch.

comment:9 by Armin K, 12 years ago

Resolution: fixed
Status: newclosed

Avahi 0.6.28 is in BLFS since SVN 2012-02-08.

comment:10 by bdubbs@…, 10 years ago

Milestone: 6.7

Milestone 6.7 deleted

Note: See TracTickets for help on using tickets.