[gentoo-dev] qpkg / portage peculiarities

[gentoo-dev] qpkg / portage peculiarities

[Stefan Boresch]

It seems that emerge/ portage up to 1.8.8-r1 (the last for the 1.0-rc6 
series) recorded md5sums in uppercase, e.g. 
(from /var/db/pkg/sys-apps/portage-1.8.8-r1/CONTENTS)

obj /usr/lib/portage/bin/dobin F397C62D816C80DEC70B17CB01A87B69 1013001542

whereas new emerge/portage-s record md5s in lower case
(from /var/db/pkg/sys-apps/portage-1.8.18/CONTENTS):

obj /usr/lib/portage/bin/dobin 81b729ded424ececf0542edff43df1a3 1018330619

Since lately qpkg reports most files of a package as having md5 errors,
I assume that qpkg expects the old form (md5s in upper case).

I can't resist the opportunity for a brief 

<rant> 

(i) Am I dreaming or is the symlink to /usr/lib/portage/bin/emerge
oscillating between /usr/bin and /usr/sbin depending on the portage
"flavor of the day.  It's clear that this is not important, but
it can lead to annoying '/usr/(s)bin/emerge not found' messages.

(ii) it would be fantastic if the man page for portage / emerge
could be kept up to date.  It simply is easier to read man emerge
than scroll back in the output of emerge --help.  Similarly, the
portage user guide accessible from the homepage is by now quite
outdated again (e.g., clean is not documented at all) Yes, one
can find (most of) the information, but it's not really in
the most visible places.

(iii) While I agree that portage is improving dramatically and
rapidly, having to (re)learn some commands every day on this core
utility doesn't strike me as the best thing for a release ...

Please don't get me wrong: I love gentoo, and we have deployed it
here on about 20 heavily used workstations since the end of last
year. Most screw-ups we encountered were our fault (and mostly
resulted from switching from 2.2.x kernels to 2.4.x etc.).  I would not have
thought of this rant if we were talking about rc6 or some
hypothetical rc7.  However, since upgrading
my experimental home machine to 1.0 I have come close to hosing
my system more often than 1.0-rc6 during the last 3 months.  
(Shouldn't it be the other way around ??)

<\rant> 

Thanks for the good work and I look forward 
to a stabilized portage ...

Stefan

-- 
Stefan Boresch
Institute for Theoretical Chemistry and Structural Molecular Biology
University of Vienna, Waehringerstr. 17       A-1090 Vienna, Austria
Phone: -43-1-427752715                        Fax:   -43-1-427752790

Re: [gentoo-dev] qpkg / portage peculiarities

[Thilo Bangert]

> (ii) it would be fantastic if the man page for portage / emerge
> could be kept up to date.  It simply is easier to read man emerge
> than scroll back in the output of emerge --help.  Similarly, the
> portage user guide accessible from the homepage is by now quite
> outdated again (e.g., clean is not documented at all) Yes, one
> can find (most of) the information, but it's not really in
> the most visible places.
>
> (iii) While I agree that portage is improving dramatically and
> rapidly, having to (re)learn some commands every day on this core
> utility doesn't strike me as the best thing for a release ...
>

i agree on this. it'd be really nice, if all these changes could be put 
on freeze and the appropriate documentation could be updated

perhaps, there should be one document that is authoritative and portage 
developers update that... right now its hard to now, what is outdated 
and what is not...

perhaps one of them is authoritative already?

<sarcasm>
its probably the ChangeLog
</sarcasm>

-- 
regards
Thilo

Re: [gentoo-dev] qpkg / portage peculiarities

[Stefan Boresch]

On Tue, Apr 09, 2002 at 04:55:30PM +0200, Thilo Bangert wrote:
> 
> <sarcasm>
> its probably the ChangeLog
> </sarcasm>

;-) Which one do you mean: From /usr/portage/sys-apps/portage/ChangeLog:

# ChangeLog for sys-apps/portage
# Copyright 2002 Gentoo Technologies, Inc.; Distributed under the GPL
# /space/gentoo/cvsroot/gentoo-x86/sys-apps/portage/ChangeLog,v 1.12
# 2002/02/28 01:11:48 drobbins Exp

See the gentoo-src Portage ChangeLog for up-to-date release information:
http://www.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-src/portage/ChangeLog?rev=HEAD&content-type=text/vnd.viewcvs-markup

I decided to bookmark this link since for now it's a must read
almost every morning ;-)

Stefan

-- 
Stefan Boresch
Institute for Theoretical Chemistry and Structural Molecular Biology
University of Vienna, Waehringerstr. 17       A-1090 Vienna, Austria
Phone: -43-1-427752715                        Fax:   -43-1-427752790

Re: [gentoo-dev] qpkg / portage peculiarities

[Edward Muller]

Lemme add to the <rant/> a bit.

Why does portage/emerge not use spython? I though (perhaps wrongly) that
was one of the main reasons for a system python. If not what other
reason is there for spython?

I think it would be best to have portage use spython so those that don't
really want a python package (I'm NOT one of them) can possibly
(depending on other deps) get away with it.

Also relying on spython instead of python would mean less problems with
people removing python IMHO.

On Tue, 2002-04-09 at 10:16, Stefan Boresch wrote:
> 
> It seems that emerge/ portage up to 1.8.8-r1 (the last for the 1.0-rc6 
> series) recorded md5sums in uppercase, e.g. 
> (from /var/db/pkg/sys-apps/portage-1.8.8-r1/CONTENTS)
> 
> obj /usr/lib/portage/bin/dobin F397C62D816C80DEC70B17CB01A87B69 1013001542
> 
> whereas new emerge/portage-s record md5s in lower case
> (from /var/db/pkg/sys-apps/portage-1.8.18/CONTENTS):
> 
> obj /usr/lib/portage/bin/dobin 81b729ded424ececf0542edff43df1a3 1018330619
> 
> Since lately qpkg reports most files of a package as having md5 errors,
> I assume that qpkg expects the old form (md5s in upper case).
> 
> I can't resist the opportunity for a brief 
> 
> <rant> 
> 
> (i) Am I dreaming or is the symlink to /usr/lib/portage/bin/emerge
> oscillating between /usr/bin and /usr/sbin depending on the portage
> "flavor of the day.  It's clear that this is not important, but
> it can lead to annoying '/usr/(s)bin/emerge not found' messages.
> 
> (ii) it would be fantastic if the man page for portage / emerge
> could be kept up to date.  It simply is easier to read man emerge
> than scroll back in the output of emerge --help.  Similarly, the
> portage user guide accessible from the homepage is by now quite
> outdated again (e.g., clean is not documented at all) Yes, one
> can find (most of) the information, but it's not really in
> the most visible places.
> 
> (iii) While I agree that portage is improving dramatically and
> rapidly, having to (re)learn some commands every day on this core
> utility doesn't strike me as the best thing for a release ...
> 
> Please don't get me wrong: I love gentoo, and we have deployed it
> here on about 20 heavily used workstations since the end of last
> year. Most screw-ups we encountered were our fault (and mostly
> resulted from switching from 2.2.x kernels to 2.4.x etc.).  I would not have
> thought of this rant if we were talking about rc6 or some
> hypothetical rc7.  However, since upgrading
> my experimental home machine to 1.0 I have come close to hosing
> my system more often than 1.0-rc6 during the last 3 months.  
> (Shouldn't it be the other way around ??)
> 
> <\rant> 
> 
> Thanks for the good work and I look forward 
> to a stabilized portage ...
> 
> Stefan
> 
> -- 
> Stefan Boresch
> Institute for Theoretical Chemistry and Structural Molecular Biology
> University of Vienna, Waehringerstr. 17       A-1090 Vienna, Austria
> Phone: -43-1-427752715                        Fax:   -43-1-427752790
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev

[gentoo-dev] Re: qpkg / portage peculiarities

[Paul]

Edward Muller <edwardam@interlix.com>, on Tue Apr 09, 2002 [12:54:18 PM] said:
> Lemme add to the <rant/> a bit.
> 
> Why does portage/emerge not use spython? I though (perhaps wrongly) that
> was one of the main reasons for a system python. If not what other
> reason is there for spython?
> 
> I think it would be best to have portage use spython so those that don't
> really want a python package (I'm NOT one of them) can possibly
> (depending on other deps) get away with it.
> 
> Also relying on spython instead of python would mean less problems with
> people removing python IMHO.
> 

	Hi;

	Having emerge use a staticly linked python makes naive
sense to me. You can end up with a dynamic python linked against
X and tcl-tk, which I believe bit some poor fellow after he
unmerged X, and his python (and thus portage) broke...
	(I believe this is true; my python isnt, but seeing
the persons post and examining the ebuild, and a tk enabled
python on another system, it seems so.)

Paul
set@pobox.com

Re: [gentoo-dev] Re: qpkg / portage peculiarities

[Edward Muller]

Good point. Dumb me just realized that the s in spython meant static,
not system.

In any case why doesn't emerge use spython?

Or for that matter, why isn't there a System Python in /usr/sbin (the
current spython is in /usr/bin) that is considered a system utility, esp
since emerge (and hence python) is a vital piece of Gentoo?


On Tue, 2002-04-09 at 13:48, Paul wrote:
> Edward Muller <edwardam@interlix.com>, on Tue Apr 09, 2002 [12:54:18 PM] said:
> > Lemme add to the <rant/> a bit.
> > 
> > Why does portage/emerge not use spython? I though (perhaps wrongly) that
> > was one of the main reasons for a system python. If not what other
> > reason is there for spython?
> > 
> > I think it would be best to have portage use spython so those that don't
> > really want a python package (I'm NOT one of them) can possibly
> > (depending on other deps) get away with it.
> > 
> > Also relying on spython instead of python would mean less problems with
> > people removing python IMHO.
> > 
> 
> 	Hi;
> 
> 	Having emerge use a staticly linked python makes naive
> sense to me. You can end up with a dynamic python linked against
> X and tcl-tk, which I believe bit some poor fellow after he
> unmerged X, and his python (and thus portage) broke...
> 	(I believe this is true; my python isnt, but seeing
> the persons post and examining the ebuild, and a tk enabled
> python on another system, it seems so.)
> 
> Paul
> set@pobox.com
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev