From: "Todd Wright" <wylie@geekasylum.org>
To: <gentoo-dev@gentoo.org>
Subject: RE: [gentoo-dev] making %95 of users happy
Date: Fri, 19 Apr 2002 04:29:52 +1000 [thread overview]
Message-ID: <NCEBJBHELIGGHDDGAEGNIEENDJAA.wylie@geekasylum.org> (raw)
In-Reply-To: <20020418122534.31311.qmail@web13308.mail.yahoo.com>
Gaarde wrote:
> Examples:
> Zope still using python 2.1 instead of 2.2...
> xcdroast using an older version of mkisofs...
> qt, kde-libs, gnome-libs, etc all using older versions of libpng...
>
> To me this is an issue with dependency calculations. Gentoo will blindly
> update a package regardless of what other packages depend on it. This
> solution works great for those who want to keep thier systems
> bleeding edge.
> However, some users are willing to make a sacrifice and go for
> less-bleeding
> edge. For those users, before mentioned pattern causes HUGH problems.
>
> The fix? In a word, sacrifice. Give the user a choice. Let the
> user decide
<snip>
> example: Upgrading to mkisofs 1.15a21 will break xcdroast
>
> xcdroast needs mkisofs 1.15a20
> cdrecord needs mkisofs 1.15a21 (it doesn't but this is an example)
This is exactly what I am concerned about, and why I posted about "Tagging releases" - and presumably what started the "Gentoo Branches" thread. The example may not be good, but the idea holds.
Regardless of if you like branches or not, there needs to be a way to lock a collective group of packages at a particular level where they all co-exist nicely. This is normally known as a "stable" release. The best and worst thing about Gentoo is that it is constantly changing - new ebuilds appearing all the time. I emerge rsync to update my portage tree in the hope of finding a fix to a broken ebuild that I want, and suddenly Im faced with new versions of things I already nailed down.
Using the =category/package parameters isnt good enough. Often 2 versions of a library wont co-exist (out of the box) - one may overwrite another, but a new ebuild for package x might require the new library, while another package requires the old.
Someone in the development team needs to seriously think about this problem.
And to the person (Andrew I think) who quoted the following from the gentoo site as a reason for not having release branches...
"*Portage allows you to set up Gentoo Linux the way you like it*..."
It doesnt. Just when I get it how I like it, it changes.
-- _--_|\ --------- Todd Wright -- wylie@geekasylum.org --------
/ \
\_.--._* <--- http://www.dreams.darker.net/~wylie/
v Mobile: +61-403-796-001 Ph: +61-2-9521-8677
----------------------------------------------------------------
next prev parent reply other threads:[~2002-04-18 18:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-18 12:25 [gentoo-dev] making %95 of users happy Gaarde
2002-04-18 18:29 ` Todd Wright [this message]
2002-04-18 19:28 ` Stefan Boresch
2002-04-19 3:25 ` Fuper
2002-04-19 12:04 ` Todd Wright
2002-04-18 22:09 ` Sherman Boyd
2002-04-19 14:15 ` Fuper
2002-04-18 19:35 ` Terje Kvernes
2002-04-19 8:42 ` Paul de Vrieze
2002-04-19 9:44 ` Terje Kvernes
2002-04-19 10:19 ` Einar Karttunen
2002-04-19 11:34 ` Mike Payson
-- strict thread matches above, loose matches on Subject: below --
2002-04-19 17:57 Gaarde
2002-04-20 0:30 ` John White
2002-04-20 18:26 Gaarde
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=NCEBJBHELIGGHDDGAEGNIEENDJAA.wylie@geekasylum.org \
--to=wylie@geekasylum.org \
--cc=gentoo-dev@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