Mailing List Archive

William Hubbs posted on Sat, 22 Aug 2009 15:52:54 -0500 as excerpted:

> On Sat, Aug 22, 2009 at 08:39:47PM +0100, Ciaran McCreesh wrote:
>> We also need to consider whether people even want it done exactly the
>> way Portage does it now. Some developers have expressed a preference
>> for a package.mask.d of some kind instead.
>
> I saw that, and I'm not sure why they suggested changing the directory
> from package.mask to package.mask.d, since all you would need to do is
> rename the file package.mask to something like package.mask/oldmasks and
> the masks in it would be preserved until you put them in different files
> in the package.mask directory and removed them from oldmasks, ultimately
> deleting oldmasks.

The (one) idea is to keep package.mask as a file for old package managers
that don't know about package.* as a directory yet. Moving package.mask
(the file) to package.mask/oldmasks wouldn't accomplish that. The
scenario people are worried about, is where (for example) someone has
gone away for their year's service (or two, or whatever) that some
nations have, and comes back and tries to upgrade, only to find the tree
is so changed that as soon as they sync, their old package manager is
broken, to the point they can't use use it to upgrade to a new version,
in ordered to be able to upgrade everything else!

Actually splitting the current single file into multiple files isn't
really a problem, and would probably be done at the same time package.mask
(.d) is made a directory, all in the same commit, so it's nothing to
worry about.

That said, in this particular instance, I don't believe that should be a
big problem. Why? Because portage has supported it for years already,
and anyone using a PM that doesn't currently support it has by definition
already demonstrated they are reasonably active about their Gentoo based
system management choices, and thus isn't likely to let a system go
unsynced and the PM unupdated for greater than say 90 days anyway. Thus,
when the policy is approved by council, stick a 90-180 day hold on
changing old profiles in the tree, and be done with it.

So ancient PMs shouldn't be a problem either way, here. Which leaves
only a simple bikeshedding issue, whether people prefer keeping the names
we have, or switching to the *.d forms in keeping with the pattern used
for all those /etc/*.d directories, of which a quick ls here demonstrated
there's about double the number I expected, having never actually counted
them before. While I'd vote for sticking with what we have, that /is/
just bikeshedding, and I REALLY want to just get on with it, regardless
of what it's named, as the feature really is quite useful.

--
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

Duncan wrote:
> William Hubbs posted on Sat, 22 Aug 2009 15:52:54 -0500 as excerpted:
>
>
>> On Sat, Aug 22, 2009 at 08:39:47PM +0100, Ciaran McCreesh wrote:
>>
>>> We also need to consider whether people even want it done exactly the
>>> way Portage does it now. Some developers have expressed a preference
>>> for a package.mask.d of some kind instead.
>>>
>> I saw that, and I'm not sure why they suggested changing the directory
>> from package.mask to package.mask.d, since all you would need to do is
>> rename the file package.mask to something like package.mask/oldmasks and
>> the masks in it would be preserved until you put them in different files
>> in the package.mask directory and removed them from oldmasks, ultimately
>> deleting oldmasks.
>>
>
> The (one) idea is to keep package.mask as a file for old package managers
> that don't know about package.* as a directory yet. Moving package.mask
> (the file) to package.mask/oldmasks wouldn't accomplish that. The
> scenario people are worried about, is where (for example) someone has
> gone away for their year's service (or two, or whatever) that some
> nations have, and comes back and tries to upgrade, only to find the tree
> is so changed that as soon as they sync, their old package manager is
> broken, to the point they can't use use it to upgrade to a new version,
> in ordered to be able to upgrade everything else!
>
> Actually splitting the current single file into multiple files isn't
> really a problem, and would probably be done at the same time package.mask
> (.d) is made a directory, all in the same commit, so it's nothing to
> worry about.
>
> That said, in this particular instance, I don't believe that should be a
> big problem. Why? Because portage has supported it for years already,
> and anyone using a PM that doesn't currently support it has by definition
> already demonstrated they are reasonably active about their Gentoo based
> system management choices, and thus isn't likely to let a system go
> unsynced and the PM unupdated for greater than say 90 days anyway. Thus,
> when the policy is approved by council, stick a 90-180 day hold on
> changing old profiles in the tree, and be done with it.
>
> So ancient PMs shouldn't be a problem either way, here. Which leaves
> only a simple bikeshedding issue, whether people prefer keeping the names
> we have, or switching to the *.d forms in keeping with the pattern used
> for all those /etc/*.d directories, of which a quick ls here demonstrated
> there's about double the number I expected, having never actually counted
> them before. While I'd vote for sticking with what we have, that /is/
> just bikeshedding, and I REALLY want to just get on with it, regardless
> of what it's named, as the feature really is quite useful.
>
>

While I like your example, if this were to happen and a couple other
things has been updated, like for example expat a while back and other
similar update nightmares, wouldn't a reinstall be easier and most
likely recommended anyway? I have seen this recommended and even made
that recommendation on -user a few times. I would also do a reinstall
on my own system if I had been gone for 6 months or more. With the
updates coming pretty fast for most things, you would most likely
recompile most everything on the system anyway. Save the configs and
the world file and just start over from a very fresh stage tarball.

It is good to look out for those braves souls that would try to update
anyway but thought it worth a mention. Would upgrading be recommended?

< back to my hole >

Dale

:-) :-)

Dale wrote:
>
> While I like your example, if this were to happen and a couple other
> things has been updated, like for example expat a while back and other
> similar update nightmares, wouldn't a reinstall be easier and most
> likely recommended anyway? I have seen this recommended and even made
> that recommendation on -user a few times. I would also do a reinstall
> on my own system if I had been gone for 6 months or more. With the
> updates coming pretty fast for most things, you would most likely
> recompile most everything on the system anyway. Save the configs and
> the world file and just start over from a very fresh stage tarball.
>
> It is good to look out for those braves souls that would try to update
> anyway but thought it worth a mention. Would upgrading be recommended?
>
> < back to my hole >
>
> Dale
>
> :-) :-)
>

Guys, if your Gentoo install is 6 months old, you're screwed anyway.
This should really be a non-issue. I just spent 2 days dealing with
being 3.5 weeks out of date. Might have been quicker to re-install.
Ooh well.

Andrew

Andrew D Kirch posted on Sun, 23 Aug 2009 04:05:03 -0400 as excerpted:

> Dale wrote:
>>
>> While I like your example, if this were to happen and a couple other
>> things has been updated, like for example expat a while back and other
>> similar update nightmares, wouldn't a reinstall be easier and most
>> likely recommended anyway? I have seen this recommended and even made
>> that recommendation on -user a few times. I would also do a reinstall
>> on my own system if I had been gone for 6 months or more. With the
>> updates coming pretty fast for most things, you would most likely
>> recompile most everything on the system anyway. Save the configs and
>> the world file and just start over from a very fresh stage tarball.

I thought that's what I argued, a bit later -- that at a year or more out
of date, there's enough going to be recompiled anyway, might as well just
do the reinstall from the latest stages, which are at least reasonably
well used and thus reasonably well debugged, rather than trying to
upgrade from a year or more out, something that's much rarer and thus
likely to be a major headache, even if there's nothing deliberately done
to kill it and no known direct incompatibilities.

And I've used the six-month figure myself. This is what I usually say:

I try to do it once a week at least (twice a week is better), to keep the
changes to something manageable, even when there's a several-hundred-
package kde upgrade. =:^P But I can see the case being made for once a
month, which would trade a few less updates (intermediate updates you
didn't see) for a bigger headache trying to manage it all, particularly
if something goes wrong. And for those on a routine monthly update
schedule, it's plausible something could delay updating a month or two,
thus making it three months. Heh, that's some people's vacation.

But at three months, I'd be beginning to consider a reinstall from
stages, tho I'd probably still do the in-place upgrade. But beyond that,
people are really only making it harder on themselves, and by six months,
I really do believe the stages method will be both cleaner and easier,
tho I could still see people trying the in-place method but I doubt I
would. But at a year, honestly, what /are/ people thinking, trying to do
the in-place upgrade? Well, I suppose it wasn't that long ago Gentoo
releng was having problems, and the install media /was/ over a year old,
but even then, at least upgrading from it would be done decently
frequently and thus be decently tested, unlike trying to upgrade in place
from some arbitrary version. But Gentoo's doing rather better in that
regard now, and with automated weekly stages, why on /earth/ would
someone put themselves thru the trouble of an in-place upgrade at a year
out, when they can do it with the far better tested weekly stages, and
just by doing that, they'll be at worst a few weeks out (if there was
some blocker and the stages for their arch hadn't built properly for a
couple weeks).

> Guys, if your Gentoo install is 6 months old, you're screwed anyway.
> This should really be a non-issue. I just spent 2 days dealing with
> being 3.5 weeks out of date. Might have been quicker to re-install. Ooh
> well.

Probably not, for 3.5 weeks. Even if that 3.5 weeks is over a big
upgrade, like a new xorg, or kde/gnome/xfce, whatever you run. At that
point, it'll be getting close, but there's still going to be major parts
of the system that are still upto date. But beyond 3 months, it's
questionable, and beyond six, yeah, just go the stages route again, it'll
be less hassle.

Actually, new thought here!

How close you are to the USE/C/CXX/LD- flags the stages are built with
could make a big difference, now. If you're running identical flags (or
close enough to it you can consider this), then for the core stages
packages, you can simply install the stages every week, and get at least
somewhat tested "near free" upgrades just doing that. If you know the
update cycle, and grab the stages the day /before/ they update, you've
just gotten yourself six days' worth of "free" testing of the exact same
packages you're using, in /addition/ to the fact that you just saved
yourself a bit of compiling.

I hadn't thought of /that/ angle before. Interesting idea! =:^) It's
been long enough since I installed (I've been doing rolling updates since
my initial install of 2004.1) that I'm not sure how /practical/ the idea
might be (are most of the packages in the tarball "limited build", thus
needing rebuilt anyway?), but if they're being built weekly now... it
really /is/ an interesting idea!

But not for me, of course, as like many Gentooers, I have my own ideas
about all those flags, and using distribution defaults brings back bad
memories of the binary based distributions... But maybe for /somebody/.
The /theory/'s there.

--
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

Duncan wrote:
> Andrew D Kirch posted on Sun, 23 Aug 2009 04:05:03 -0400 as excerpted:
>
>
>> Dale wrote:
>>
>>> While I like your example, if this were to happen and a couple other
>>> things has been updated, like for example expat a while back and other
>>> similar update nightmares, wouldn't a reinstall be easier and most
>>> likely recommended anyway? I have seen this recommended and even made
>>> that recommendation on -user a few times. I would also do a reinstall
>>> on my own system if I had been gone for 6 months or more. With the
>>> updates coming pretty fast for most things, you would most likely
>>> recompile most everything on the system anyway. Save the configs and
>>> the world file and just start over from a very fresh stage tarball.
>>>
>
> I thought that's what I argued, a bit later -- that at a year or more out
> of date, there's enough going to be recompiled anyway, might as well just
> do the reinstall from the latest stages, which are at least reasonably
> well used and thus reasonably well debugged, rather than trying to
> upgrade from a year or more out, something that's much rarer and thus
> likely to be a major headache, even if there's nothing deliberately done
> to kill it and no known direct incompatibilities.
>
> And I've used the six-month figure myself. This is what I usually say:
>
> I try to do it once a week at least (twice a week is better), to keep the
> changes to something manageable, even when there's a several-hundred-
> package kde upgrade. =:^P But I can see the case being made for once a
> month, which would trade a few less updates (intermediate updates you
> didn't see) for a bigger headache trying to manage it all, particularly
> if something goes wrong. And for those on a routine monthly update
> schedule, it's plausible something could delay updating a month or two,
> thus making it three months. Heh, that's some people's vacation.
>
> But at three months, I'd be beginning to consider a reinstall from
> stages, tho I'd probably still do the in-place upgrade. But beyond that,
> people are really only making it harder on themselves, and by six months,
> I really do believe the stages method will be both cleaner and easier,
> tho I could still see people trying the in-place method but I doubt I
> would. But at a year, honestly, what /are/ people thinking, trying to do
> the in-place upgrade? Well, I suppose it wasn't that long ago Gentoo
> releng was having problems, and the install media /was/ over a year old,
> but even then, at least upgrading from it would be done decently
> frequently and thus be decently tested, unlike trying to upgrade in place
> from some arbitrary version. But Gentoo's doing rather better in that
> regard now, and with automated weekly stages, why on /earth/ would
> someone put themselves thru the trouble of an in-place upgrade at a year
> out, when they can do it with the far better tested weekly stages, and
> just by doing that, they'll be at worst a few weeks out (if there was
> some blocker and the stages for their arch hadn't built properly for a
> couple weeks).
>
>
>> Guys, if your Gentoo install is 6 months old, you're screwed anyway.
>> This should really be a non-issue. I just spent 2 days dealing with
>> being 3.5 weeks out of date. Might have been quicker to re-install. Ooh
>> well.
>>
>
> Probably not, for 3.5 weeks. Even if that 3.5 weeks is over a big
> upgrade, like a new xorg, or kde/gnome/xfce, whatever you run. At that
> point, it'll be getting close, but there's still going to be major parts
> of the system that are still upto date. But beyond 3 months, it's
> questionable, and beyond six, yeah, just go the stages route again, it'll
> be less hassle.
>
> Actually, new thought here!
>
> How close you are to the USE/C/CXX/LD- flags the stages are built with
> could make a big difference, now. If you're running identical flags (or
> close enough to it you can consider this), then for the core stages
> packages, you can simply install the stages every week, and get at least
> somewhat tested "near free" upgrades just doing that. If you know the
> update cycle, and grab the stages the day /before/ they update, you've
> just gotten yourself six days' worth of "free" testing of the exact same
> packages you're using, in /addition/ to the fact that you just saved
> yourself a bit of compiling.
>
> I hadn't thought of /that/ angle before. Interesting idea! =:^) It's
> been long enough since I installed (I've been doing rolling updates since
> my initial install of 2004.1) that I'm not sure how /practical/ the idea
> might be (are most of the packages in the tarball "limited build", thus
> needing rebuilt anyway?), but if they're being built weekly now... it
> really /is/ an interesting idea!
>
> But not for me, of course, as like many Gentooers, I have my own ideas
> about all those flags, and using distribution defaults brings back bad
> memories of the binary based distributions... But maybe for /somebody/.
> The /theory/'s there.
>
>

I think we agree more than disagree. It mostly depends on what updates
there has been and if the fancy new portage can get past any blockages
and make the needed fixes. I guess whether it is a year, six months or
even three months depends on what has been updated, what has to be
recompiled and how difficult it is to configure them afterwards. Right
now, after the recent python upgrade, I'm recompiling over 60 packages
including OOo. If it meant recompiling most of KDE, then a reinstall
may be faster.

I'm just not sure that portage should be soooo backward compatible as it
appears to be now.

Dale

:-) :-)

Dale wrote:
>
> I'm just not sure that portage should be soooo backward compatible as it
> appears to be now.
>
Dale,

It really doesn't have to, unless you're not running portage... in which
case we have to wait on all package managers to implement every major
feature change the others want. The result of this was PMS and EAPIs.
These are an effort to define feature sets the PM's can agree on.

Interestingly some package managers, or perhaps their developers, are
louder and more abrasive than others. This is causing an overall
reduction in the implementation speed of these EAPI's and quite a bit of
confusion with 10.0, along with much wharrgarbl and FUD. It also
consumed nearly the entire agenda of the previous Gentoo Council.
Things are getting better though.

Andrew D Kirch
Funtoo.org

Le dimanche 23 août 2009 à 10:24 +0000, Duncan a écrit :
> But at three months, I'd be beginning to consider a reinstall from
> stages, tho I'd probably still do the in-place upgrade. But beyond
> that,
> people are really only making it harder on themselves, and by six
> months,

It really depends on the packages you are using. I've updated machines
over 6 month old period (which got to this state for whatever reason,
doesn't matter) and it was just a breeze to update because there wasn't
that much packages that changed in an "upgrade blocker" way. Plus all
the hard work was done on the binary building machine. It would have
been much longer to re-install 10+ machines. So please don't generalize
your experience with fast moving packages to the tree.

--
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo