Bug 197905

Summary:	portage should retain order of messages regardless of type
Product:	Portage Development	Reporter:	Petteri Räty (RETIRED) <betelgeuse>
Component:	Core - Ebuild Support	Assignee:	Portage team <dev-portage>
Status:	RESOLVED FIXED
Severity:	normal	CC:	jakub
Priority:	High	Keywords:	InVCS
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---
Bug Depends on:
Bug Blocks:	216231

Description Petteri Räty (RETIRED) gentoo-dev

2007-11-02 23:32:36 UTC

* Messages for package net-misc/dhcpcd-3.1.7:

 * This means that we will generate a DUID in /var/lib/dhcpcd/dhcpcd.duid
 * This is generated from a MAC address of the card and a timestamp.
 * It will be used in every subsequent DHCP transaction, along with a IAID
 * in the ClientID option. This is required by RFC 4361.
 * You have installed dhcpcd with DUID support.
 * Some DHCP server implementations require a MAC address only in the
 * ClientID field. These DHCP servers should be updated to be RFC
 * conformant. If you cannot do this, you can revert to the old
 * behaviour by using the -I '' option OR building dhcpcd with the
 * vram USE flag enabled.

See how it comes out of order here.

		ewarn "You have installed dhcpcd with DUID support."
		elog "This means that we will generate a DUID in /var/lib/dhcpcd/dhcpcd.duid"
		elog "This is generated from a MAC address of the card and a timestamp."
		elog "It will be used in every subsequent DHCP transaction, along with a IAID"
		elog "in the ClientID option. This is required by RFC 4361."

For example change the first ewarn to elog. Same problem seems to exist with the zeroconf message.

Comment 1 Jakub Moc (RETIRED) gentoo-dev

2007-11-02 23:47:02 UTC

Eh, seriously portage should stop being overly smart. Why's it re-ordering the messages in the first place?

Comment 2 Zac Medico gentoo-dev

2007-11-03 00:32:13 UTC

(In reply to comment #1)
> Eh, seriously portage should stop being overly smart. Why's it re-ordering the
> messages in the first place?

It's not trying to be smart. It's actually just a limitation of the way elog is implemented by using a separate file for each message type.  I suppose it wouldn't be too difficult to re-implement it in a way that preserves order across all message types.

Comment 3 Zac Medico gentoo-dev

2008-04-13 04:34:50 UTC

This is fixed in 2.1.5_rc3.