public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: kensington@gentoo.org
Subject: Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes
Date: Sun, 28 Jul 2013 11:11:13 +0200	[thread overview]
Message-ID: <20130728111113.318cdc6a@gentoo.org> (raw)
In-Reply-To: <ksqiqd$dbf$1@ger.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]

Dnia 2013-07-25, o godz. 17:07:00
Michael Palimaka <kensington@gentoo.org> napisał(a):

> On 25/07/2013 05:17, Michał Górny wrote:
> > Actually per PMS you are required to revbump (and therefore require
> > upgrade on users' side) whenever you change the deps and don't expect
> > to add a new version soon enough.
> 
> Can you please provide a link/reference to that part? I am interested in 
> reading more about it.

To be honest, I have no idea if that's worded at all since PMS doesn't
cover vardb. I may have overused the term 'per PMS' then.

However, this is what Brian & Ciaran (at least) were criticizing for
some time. The idea is that when you build an ebuild, you are basically
either creating a binary package or installing a package to the system
(or both). Along with that, metadata is transferred from the ebuild to
the package or vardb.

With a proper design, you have two 'repos': one with ebuilds,
and the other consisting purely of installed packages (vardb/system).
What's important, per definition vardb is self-satisfactory. That is,
dependencies of every installed package are supposed to be satisfied by
installed packages purely.

Now, what portage does is implicitly applying _some_ of the metadata
from the ebuild tree to vardb without rebuilding the package. In some
cases. As an effect, vardb is no longer self-satisfactory,
and represents something between the package that was built
and the current ebuild.

Ciaran has already elaborated a bit on the potential issues. It gets
most dangerous when you create some meaningful changes without
a revbump. I'll give you a simple example that I can think of.

Say, you fix a semi-build-time issue of linking against unnecessary
dep. Users who build the ebuild from now on benefit by having less
deps. The dep is less problematic than rebuilding the package, so users
who built it before prefer to wait for next version.

But in this case, portage may implicitly update the deps from ebuild
without rebuilding it. This means that users who still link against
the dep, may end up with the dep removed and program broken.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

  reply	other threads:[~2013-07-28  9:11 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-24 12:49 [gentoo-dev] revbumping ebuilds after USE dependency changes Alex Alexander
     [not found] ` < CAJ0EP43edWPPYXXMOQPL4V2ZdO8R4YArpcNJK5cgBOqahzVdYw@mail.gmail.com>
2013-07-24 14:15 ` Mike Gilbert
2013-07-24 15:31   ` Alex Alexander
2013-07-24 15:48     ` "Paweł Hajdan, Jr."
     [not found]       ` < 20130724132315.19acde44@caribou.gateway.2wire.net>
2013-07-24 19:23       ` [gentoo-dev] " Ryan Hill
2013-07-24 19:17         ` Michał Górny
2013-07-24 19:18           ` Ciaran McCreesh
2013-07-25  0:53             ` Rick "Zero_Chaos" Farina
2013-07-25  3:50               ` "Paweł Hajdan, Jr."
2013-07-25  3:54                 ` Zac Medico
2013-07-25 15:29                   ` Rick "Zero_Chaos" Farina
2013-07-25 17:28                     ` Zac Medico
2013-07-25 18:29                       ` Rick "Zero_Chaos" Farina
2013-07-25 18:36                         ` Zac Medico
2013-07-24 19:40           ` Ryan Hill
2013-07-24 19:44             ` Ciaran McCreesh
2013-07-25  7:07           ` Michael Palimaka
2013-07-28  9:11             ` Michał Górny [this message]
2013-07-28 12:37               ` Kent Fredric
     [not found]             ` <20130728111113.318cdc6a@gentoo. org>
2013-07-29  0:39               ` Duncan
2013-07-29  8:04                 ` Zac Medico
2013-07-29 11:03                   ` Duncan
2013-07-24 17:54   ` [gentoo-dev] " Davide Pesavento
2013-07-25  7:43 ` Dale

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130728111113.318cdc6a@gentoo.org \
    --to=mgorny@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=kensington@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox