FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-30-2010, 04:11 PM
Pacho Ramos
 
Default Reminder: please use the latest Portage/repoman version to commit to tree

El jue, 30-09-2010 a las 08:19 -0700, Zac Medico escribió:
> If we don't find any really annoying regressions in portage-2.1.9.12
> then that release will be stabilized about 30 days from now. We
> haven't been finding many regressions lately [1], so there's a
> reasonable probability of this release being stabilized.
>
> [1] http://bugs.gentoo.org/show_bug.cgi?id=335925

OK, thanks :-)
 
Old 09-30-2010, 05:48 PM
Petteri Räty
 
Default Reminder: please use the latest Portage/repoman version to commit to tree

On 09/30/2010 06:25 PM, Zac Medico wrote:
> On 09/30/2010 12:41 AM, Dirkjan Ochtman wrote:
>> As another dev who generally runs stable (except things that I hack
>> on), another question: is it actually possible, as Diego seems to
>> suggest, to have two portages installed?
>
> You can run portage directly from a checkout if you export modified
> versions of the PATH and PYTHONPATH variables as described here:
>
> http://www.gentoo.org/proj/en/portage/doc/testing.xml

This could also just be a unpacked release.

Regards,
Petteri
 
Old 09-30-2010, 06:15 PM
Duncan
 
Default Reminder: please use the latest Portage/repoman version to commit to tree

Andreas K. Huettel posted on Thu, 30 Sep 2010 09:36:44 +0200 as excerpted:

> as I've only recently "graduated to developer", I've got a question
> about this. Diego, your request makes perfect sense to me. But, so far I
> always thought "Python, portage, and gcc are the things that I really
> need to rely on, so whatever I do, I'll keep those stable."
>
> (My development machine(s) are also my real-life work machines.)

The main topic is portage, here, but since you brought up the bigger
question...

1) For gcc, keep in mind that it's both slotted and easy to change running
versions using gcc-config. I run ~arch here, not stable, but take
advantage of the slotting to test out still hard-masked versions before
~arch gets them.

The caveat is C++, due to libstdc++ being part of gcc, so if you're
running anything like KDE that has really complex dependencies and is C++,
you'll probably want to switch that all at once, to avoid issues like I've
had before with some parts of it not building with the new gcc, but cmake
being built with the new gcc, so they won't build with the old one
either. (FWIW, I've been running 100% gcc 4.5 for a few months, no probs
at all, due to flameeyes tinderbox work! =:^) YMMV of course.)

2) If you don't think glibc is vital enough for that list, you've never
had it break! (Again, I run full ~arch, and remember once when glibc's
symlinks got broken. It was "interesting" but I was able to recover
without going to my recovery partition.) Bash can be vital as well, tho
if you have another shell it's not /so/ bad.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 10-04-2010, 07:50 AM
Michael Haubenwallner
 
Default Reminder: please use the latest Portage/repoman version to commit to tree

On 09/30/2010 09:36 AM, Andreas K. Huettel wrote:
> as I've only recently "graduated to developer", I've got a question about
> this. Diego, your request makes perfect sense to me. But, so far I always
> thought "Python, portage, and gcc are the things that I really need to rely
> on, so whatever I do, I'll keep those stable."
>
> (My development machine(s) are also my real-life work machines.)

As I do second these concerns, another thought:

While /portage/ is vital to our distro (not only) for end users (including
devs doing their workwork on Gentoo systems), /repoman/ isn't.

So - would it make sense to split repoman into its own ebuild?

/haubi/
--
Michael Haubenwallner
Gentoo on a different level
 
Old 10-04-2010, 03:08 PM
Richard Freeman
 
Default Reminder: please use the latest Portage/repoman version to commit to tree

On 10/04/2010 03:50 AM, Michael Haubenwallner wrote:
> So - would it make sense to split repoman into its own ebuild?

++

I always did wonder why the two have been part of the same project.
Repoman updates could probably be stabilized more quickly with so much
worry about impact on users at large.

Rich
 
Old 10-04-2010, 03:45 PM
Fabio Erculiani
 
Default Reminder: please use the latest Portage/repoman version to commit to tree

Am I the only one who is waiting for a Portage 2.2 unmask on ~arch?
It's taking months if not years ;-)

--
Fabio Erculiani
 
Old 10-04-2010, 05:36 PM
Zac Medico
 
Default Reminder: please use the latest Portage/repoman version to commit to tree

On 10/04/2010 08:45 AM, Fabio Erculiani wrote:
> Am I the only one who is waiting for a Portage 2.2 unmask on ~arch?
> It's taking months if not years ;-)

Well, portage-2.1.9.x is essentially the same codebase as "portage-2.2".
If you look at the 2.1.9 branch, you can see that it diverges and at the
following commit:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=efebcb2ba1ab706b2fd69521a0b 0e4d1c28abe9d

This commit disables features that I consider to be unstable. Rather
than try to answer the question "when will all these features will be
stable," I'd prefer to ask you "which features you'd most like to have
stabilized" so that we can focus our efforts on getting those specific
features stabilized.
--
Thanks,
Zac
 
Old 10-04-2010, 05:40 PM
Zac Medico
 
Default Reminder: please use the latest Portage/repoman version to commit to tree

On 10/04/2010 12:50 AM, Michael Haubenwallner wrote:
>
> On 09/30/2010 09:36 AM, Andreas K. Huettel wrote:
>> as I've only recently "graduated to developer", I've got a question about
>> this. Diego, your request makes perfect sense to me. But, so far I always
>> thought "Python, portage, and gcc are the things that I really need to rely
>> on, so whatever I do, I'll keep those stable."
>>
>> (My development machine(s) are also my real-life work machines.)
>
> As I do second these concerns, another thought:
>
> While /portage/ is vital to our distro (not only) for end users (including
> devs doing their workwork on Gentoo systems), /repoman/ isn't.
>
> So - would it make sense to split repoman into its own ebuild?
>
> /haubi/

The thing is, parts of repoman are closely coupled to portage internals.
So, if we split it out then in practice we'd end up having to do repoman
version bumps to correspond with portage version bumps, which would
eliminate any practical gain that we'd get from distributing it with a
separate ebuild.
--
Thanks,
Zac
 
Old 10-05-2010, 04:13 AM
Duncan
 
Default Reminder: please use the latest Portage/repoman version to commit to tree

Zac Medico posted on Mon, 04 Oct 2010 10:40:29 -0700 as excerpted:

> On 10/04/2010 12:50 AM, Michael Haubenwallner wrote:
>>
>> On 09/30/2010 09:36 AM, Andreas K. Huettel wrote:
>>> [Portage is something] that I really need to rely on,
>>> so whatever I do, I'll keep [it] stable.
>>>
>>> (My development machine(s) are also my real-life work machines.)

>> So - would it make sense to split repoman into its own ebuild?

> The thing is, parts of repoman are closely coupled to portage internals.
> So, if we split it out then in practice we'd end up having to do repoman
> version bumps to correspond with portage version bumps, which would
> eliminate any practical gain that we'd get from distributing it with a
> separate ebuild.

Accepting what you wrote at face value, we've established that there must
be a repoman version for each portage version (or rather, portage series).

But does the inverse also hold, that for each repoman version there must
be a portage version? IOW, is there a 1:1 correspondence or can it be
1:x, where x varies?

So in the context of this thread, it would then be possible to release a
repoman with the new feature/warning, one-each for each current portage
series (three, now, stable, ~arch and masked-2.2, four if HEAD is also
counted). Of course this wouldn't work for repoman features that are very
closely tied to new portage features, not yet in stable portage, but it
could work for others. Each current portage series would then have at
least one repoman version, but where needed, they could "tick" separately,
simply kept series-synced with a new repoman version for each portage
series when necessary.

But it could also well be that while such is possible, it'd be so much
more work that it's not practical, as it would ultimately drive our ever-
patient portage devs to burn-out. =:^( I don't know. I'm simply asking.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 10-05-2010, 06:44 AM
Zac Medico
 
Default Reminder: please use the latest Portage/repoman version to commit to tree

On 10/04/2010 09:13 PM, Duncan wrote:
> Zac Medico posted on Mon, 04 Oct 2010 10:40:29 -0700 as excerpted:
>
>> On 10/04/2010 12:50 AM, Michael Haubenwallner wrote:
>>>
>>> On 09/30/2010 09:36 AM, Andreas K. Huettel wrote:
>>>> [Portage is something] that I really need to rely on,
>>>> so whatever I do, I'll keep [it] stable.
>>>>
>>>> (My development machine(s) are also my real-life work machines.)
>
>>> So - would it make sense to split repoman into its own ebuild?
>
>> The thing is, parts of repoman are closely coupled to portage internals.
>> So, if we split it out then in practice we'd end up having to do repoman
>> version bumps to correspond with portage version bumps, which would
>> eliminate any practical gain that we'd get from distributing it with a
>> separate ebuild.
>
> Accepting what you wrote at face value, we've established that there must
> be a repoman version for each portage version (or rather, portage series).
>
> But does the inverse also hold, that for each repoman version there must
> be a portage version? IOW, is there a 1:1 correspondence or can it be
> 1:x, where x varies?
>
> So in the context of this thread, it would then be possible to release a
> repoman with the new feature/warning, one-each for each current portage
> series (three, now, stable, ~arch and masked-2.2, four if HEAD is also
> counted). Of course this wouldn't work for repoman features that are very
> closely tied to new portage features, not yet in stable portage, but it
> could work for others. Each current portage series would then have at
> least one repoman version, but where needed, they could "tick" separately,
> simply kept series-synced with a new repoman version for each portage
> series when necessary.

Yeah, I supposed that would work. However, I don't see new repoman
checks being being added quickly enough to make it worth the effort. If
people just have a little patience then the portage with the latest
repoman checks will be stabilized soon enough.

> But it could also well be that while such is possible, it'd be so much
> more work that it's not practical, as it would ultimately drive our ever-
> patient portage devs to burn-out. =:^( I don't know. I'm simply asking.

Well, I just don't see a good benefit/cost ratio here. I don't think
people will be getting shiny new repoman features fast enough to make it
worth the extra effort.
--
Thanks,
Zac
 

Thread Tools




All times are GMT. The time now is 04:04 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org