When browsing through emerge logs (using elogv) I often come across
stuff that doesn't affect me. Two examples:
x11-base/xorg-server-1.7.6 warns:
You must rebuild all drivers if upgrading from xorg-server 1.6
or earlier, because the ABI changed.
dev-db/mysql-5.1.45-r1 logs:
You might want to run: "emerge --config =dev-db/mysql-1.45-r1"
if this is a new install.
I had xorg 1.7.x running before so that's pure noise in my case.
Same with mysql - I had it installed before.
So I am wondering: Why aren't people using has_version to catch such
cases and omit things that we have seen before or that don't affect us?
has_version -- "Returns 1 if the system has the requested
version of a certain package. For instance
has_version >=sys-libs/glibc-2.3.0."
Is it lazyness? Is it unawareness? Is there some kind of evilness in
this usage of has_version that I am not aware of?
Do we need a better framework for this? If so what could it look like?
What do you think?
Sebastian
03-31-2010, 08:19 PM
Ciaran McCreesh
Unnecessary logs: has_version to the rescue?
On Wed, 31 Mar 2010 22:08:40 +0200
Sebastian Pipping <sping@gentoo.org> wrote:
> Is there some kind of evilness in this usage of has_version that I am
> not aware of?
Unfortunately, yes.
Historically, has_version in pkg_postinst would return results based
upon the version that *was* installed. This feature was widely used to
display context-aware post-install messages, and there were examples of
it in the documentation. Portage then silently changed this behaviour,
without an EAPI bump and without changing the documentation, breaking
all those packages in the process. The resulting mess discouraged many
people from bothering with that kind of thing...
--
Ciaran McCreesh
03-31-2010, 08:29 PM
Sebastian Pipping
Unnecessary logs: has_version to the rescue?
On 03/31/10 22:19, Ciaran McCreesh wrote:
>> Is there some kind of evilness in this usage of has_version that I am
>> not aware of?
>
> Unfortunately, yes.
>
> Historically, has_version in pkg_postinst would return results based
> upon the version that *was* installed.
What's status quo? What did it switch to?
Sebastian
03-31-2010, 08:31 PM
Zac Medico
Unnecessary logs: has_version to the rescue?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/31/2010 01:19 PM, Ciaran McCreesh wrote:
> On Wed, 31 Mar 2010 22:08:40 +0200
> Sebastian Pipping <sping@gentoo.org> wrote:
>> Is there some kind of evilness in this usage of has_version that I am
>> not aware of?
>
> Unfortunately, yes.
>
> Historically, has_version in pkg_postinst would return results based
> upon the version that *was* installed. This feature was widely used to
> display context-aware post-install messages, and there were examples of
> it in the documentation. Portage then silently changed this behaviour,
> without an EAPI bump and without changing the documentation, breaking
> all those packages in the process. The resulting mess discouraged many
> people from bothering with that kind of thing...
For those who may not know, has_version can be called in pkg_preinst
to find the previous version, and the result can be stored in a
variable for us in pkg_postinst.
We also have plans for a REPLACING_VERSIONS variable which would be
useful in similar cases:
On Wed, 31 Mar 2010 22:29:50 +0200
Sebastian Pipping <sping@gentoo.org> wrote:
> On 03/31/10 22:19, Ciaran McCreesh wrote:
> >> Is there some kind of evilness in this usage of has_version that I
> >> am not aware of?
> >
> > Unfortunately, yes.
> >
> > Historically, has_version in pkg_postinst would return results based
> > upon the version that *was* installed.
>
> What's status quo? What did it switch to?
Now you really need to use REPLACING_VERSIONS to do it cleanly, but
that's only in EAPI 4, which still isn't implemented in Portage. As a
hack, you can instead do the has_version check in pkg_preinst and use
environment variable saving to get the result in pkg_postinst. It is
not exactly pretty.
--
Ciaran McCreesh
03-31-2010, 08:37 PM
Sebastian Pipping
Unnecessary logs: has_version to the rescue?
On 03/31/10 22:31, Zac Medico wrote:
> For those who may not know, has_version can be called in pkg_preinst
> to find the previous version, and the result can be stored in a
> variable for us in pkg_postinst.
So has_version takes the version just installed into account when called
from pkg_postinst? If so wouldn't be banning it's usage from that stage
a good idea? I just checked the code, no such check, yet.
Sebastian
03-31-2010, 08:42 PM
Zac Medico
Unnecessary logs: has_version to the rescue?
On 03/31/2010 01:37 PM, Sebastian Pipping wrote:
> On 03/31/10 22:31, Zac Medico wrote:
>> For those who may not know, has_version can be called in pkg_preinst
>> to find the previous version, and the result can be stored in a
>> variable for us in pkg_postinst.
>
> So has_version takes the version just installed into account when called
> from pkg_postinst? If so wouldn't be banning it's usage from that stage
> a good idea? I just checked the code, no such check, yet.
Well, it works fine when not called for the same $CATEGORY/$PN, and
even for the same $CATEGORY/$PN it works fine for other slots it
they happen to be installed.
--
Thanks,
Zac
03-31-2010, 08:52 PM
Sebastian Pipping
Unnecessary logs: has_version to the rescue?
On 03/31/10 22:42, Zac Medico wrote:
> Well, it works fine when not called for the same $CATEGORY/$PN, and
> even for the same $CATEGORY/$PN it works fine for other slots it
> they happen to be installed.
Good point. So the check would be:
Deny calling has_version if all of:
- in postinst stage
- same category and package
- same slot
How about that?
Sebastian
03-31-2010, 09:05 PM
Zac Medico
Unnecessary logs: has_version to the rescue?
On 03/31/2010 01:52 PM, Sebastian Pipping wrote:
> On 03/31/10 22:42, Zac Medico wrote:
>> Well, it works fine when not called for the same $CATEGORY/$PN, and
>> even for the same $CATEGORY/$PN it works fine for other slots it
>> they happen to be installed.
>
> Good point. So the check would be:
>
> Deny calling has_version if all of:
> - in postinst stage
> - same category and package
> - same slot
>
> How about that?
Yeah, but the "same slot" thing is a little ambiguous since the
given atom could possibly match multiple slots that include the one
whose postinst is currently running. So, I'd make has_version
generate a QA warning if has_version is called there and the given
atom only matches the one whose postinst is currently running.
--
Thanks,
Zac
03-31-2010, 09:16 PM
Sebastian Pipping
Unnecessary logs: has_version to the rescue?
On 03/31/10 23:05, Zac Medico wrote:
> Yeah, but the "same slot" thing is a little ambiguous since the
> given atom could possibly match multiple slots that include the one
> whose postinst is currently running. So, I'd make has_version
> generate a QA warning if has_version is called there and the given
> atom only matches the one whose postinst is currently running.
Unnecessary logs: has_version to the rescue?
