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.
next prev parent 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