public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Patrick Lauer <patrick@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Gentoo Council Reminder for May 28
Date: Thu, 28 May 2009 08:36:57 +0200	[thread overview]
Message-ID: <200905280836.57306.patrick@gentoo.org> (raw)
In-Reply-To: <d77765540905271610q39e52796vf0ef613e17c78f8f@mail.gmail.com>

On Thursday 28 May 2009 01:10:50 Piotr Jaroszyński wrote:

> >>
> >> How is it one-way exactly? You can do pretty much anything you want in
> >> a new EAPI (that's the point).
> >
> > You cannot undo it.
> >
> > In other words, you'll have to allow stupid filenames until the end of
> > times even if you are quite positively sure that it is, right now, a bad
> > idea.
>
> What do you mean by "allow" exactly? You can put whatever filenames in
> the tree currently and package managers ignore them, just as they
> would ignore *.ebuild-$eapi where $eapi is unsupported. So should g55
> be accepted, implemented and then undone you would "lose" only
> *.ebuild-{EAPIs introduced before undoing}.

If you add an unsupported filetype randomly you'll find a few very unhappy 
people reverting your commit and suggesting that you never do it again. And 
repoman will tell you not to do such things (assuming that you do use it)

Once you GLEP55 it is very difficult to get rid of any problems it might cause 
without triggering the kind of apocalyptic breakage that it is supposed to 
avoid. So we should be reasonably certain that it is in fact the best solution 
and we want to live with it for a long time.

But, as people are discussing some interesting new (and some old) concepts 
that might change things around quite a bit maybe we should wait until we know 
where we are going before we start changing things we'd revert immediately.

> > Not at all. Just an upgrade snapshot so you can get "old" users into a
> > known state, then let them upgrade at least the package manager to a
> > point where they can use the rest. That snapshot should be seen as a
> > transient helper, not as a "release" ...
>
> So a user n snapshots behind would have to go through various upgrade
> paths n times. And if she failed to do it all at once her system would
> be left with known bugs and vulnerabilities. Sounds a bit messy to me,
> especially as it can be easily avoided (with improved EAPIs - i.e.
> g55).
It's actually less messy than the current breakage. Just spend a few days in 
#gentoo and watch people try to upgrade after >1y ... glep55 does nothing at 
all to help with that, snapshots at least give a consistent state to converge 
to. E.g. the bash-portage blocker (easily avoided with a snapshot), the "EAPI1 
unsupported" blocker (same) etc. etc.

Most issues happen because we do not provide an upgrade path, and GLEP55-style 
changes only motivate more rapid changes that will not make it easier for 
users to upgrade. It only has the potential to make life easier for those of 
use living on the bleeding edge and allows to add package formats to the tree 
that no official package manager supports (do we want that? I vote for no)

Added bonus - as soon as you have a snapshot supporting EAPI="wintermute" you 
can migrate _all_ packages to it without having to keep Python and gcc and 
stuff as eapi0. Which means we lose some rather naughty restrictions that are 
in place now (and can easily deprecate older EAPIs too, which is good in terms 
of complexity)
Oh, and you can change the defaults around too because you _know_ that this 
snapshot and higher can handle this change. 

I could go on pointing out nice features, but since this isn't a sales 
brochure I'll just leave it at that and hope someone actually reads this mail 
before instareplying.




  reply	other threads:[~2009-05-28  6:37 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-26 18:57 [gentoo-dev] Gentoo Council Reminder for May 28 Tiziano Müller
2009-05-27 12:46 ` Ferris McCormick
2009-05-27 13:25   ` Ulrich Mueller
2009-05-27 19:55   ` Roy Bamford
2009-05-27 20:06     ` Ciaran McCreesh
2009-05-27 21:43       ` Roy Bamford
2009-05-27 21:52         ` Ciaran McCreesh
2009-05-27 23:26           ` [gentoo-dev] " Mark Bateman
2009-05-27 23:45             ` Ciaran McCreesh
2009-05-27 23:48               ` Jeroen Roovers
2009-05-27 23:54                 ` Ciaran McCreesh
2009-05-28  3:58                   ` Jeroen Roovers
2009-05-28  6:28               ` [gentoo-dev] How not to discuss Patrick Lauer
2009-05-28 18:14                 ` Ciaran McCreesh
2009-05-28 18:36                   ` Alec Warner
2009-05-28 18:58                     ` Roy Bamford
2009-05-28 19:15                     ` Joe Peterson
2009-05-28 19:40                       ` Piotr Jaroszyński
2009-05-29  9:23                         ` Marijn Schouten (hkBst)
2009-05-30  0:38                       ` Alec Warner
2009-05-30 15:08                         ` Joe Peterson
2009-05-28 18:49                   ` Patrick Lauer
2009-05-28 19:11                     ` Ciaran McCreesh
2009-05-29  2:41                   ` [gentoo-dev] " Duncan
2009-05-29  2:12                 ` Ryan Hill
2009-05-29 21:49                   ` Patrick Lauer
2009-05-30 20:56                     ` Ryan Hill
2009-05-31  1:57                       ` Richard Freeman
2009-05-31  9:25                         ` Thilo Bangert
2009-05-31 10:57                           ` Duncan
2009-05-31 22:01                             ` Richard Freeman
2009-06-02  8:20                             ` Steven J Long
2009-06-02 12:53                               ` Duncan
2009-06-04 14:11                                 ` Steven J Long
2009-06-02 15:38                               ` Richard Freeman
2009-06-03 10:43                                 ` Marijn Schouten (hkBst)
2009-06-03 18:23                                   ` Richard Freeman
2009-05-28  5:46         ` [gentoo-dev] Gentoo Council Reminder for May 28 Tiziano Müller
2009-05-28  7:23           ` Patrick Lauer
2009-05-28  9:35             ` Tiziano Müller
2009-05-28 17:56           ` Roy Bamford
2009-05-28 18:04             ` Ciaran McCreesh
2009-05-28 18:30               ` Patrick Lauer
2009-05-28 18:48                 ` Ciaran McCreesh
2009-05-28 19:19                   ` Patrick Lauer
2009-05-28 19:26                     ` Ciaran McCreesh
2009-05-28 19:42                       ` Josh Saddler
2009-05-28 19:43                         ` Ciaran McCreesh
2009-05-28 19:42                       ` Roy Bamford
2009-05-28 19:54                         ` Ciaran McCreesh
2009-05-28 21:31                           ` Roy Bamford
2009-05-28 19:46                       ` Patrick Lauer
2009-05-28 19:52                         ` Ciaran McCreesh
2009-05-28 20:56                           ` Patrick Lauer
2009-05-28 21:09                             ` Ciaran McCreesh
2009-05-27 20:57     ` Joe Peterson
2009-05-27 21:58       ` Patrick Lauer
2009-05-27 22:12         ` Piotr Jaroszyński
2009-05-27 22:33           ` Patrick Lauer
2009-05-27 23:10             ` Piotr Jaroszyński
2009-05-28  6:36               ` Patrick Lauer [this message]
2009-06-01 20:42     ` Tiziano Müller
2009-05-28 13:11   ` Ferris McCormick

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=200905280836.57306.patrick@gentoo.org \
    --to=patrick@gentoo.org \
    --cc=gentoo-dev@lists.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