Re: [gentoo-user] quickpkg

2005-03-27 Thread Grant
> > If I'm understanding it correctly, FEATURES="buildpkg" sounds less
> > reliable for failed upgrade recovery.  If you want to roll back to a
> > previous version of a package, you're going to end up with what was
> > originally installed, not what was working on your system right before
> > the upgrade, right?
> 
> Wrong. buildpkg builds a binary package for each package before installing
> it, so you have the current version and all previous versions, since you
> enabled buildpkg, in PKGDIR. It means you can rol back as far as you like.

Ok, I was thinking it wouldn't take into account changes you make
since it was installed, but the only changes should be in /etc/ and
those would be preserved.  I see buildpkg and quickpkg both utilize
$PKGDIR.  Very nice.

- Grant

> Neil Bothwick
--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] quickpkg

2005-03-27 Thread Neil Bothwick
On Sun, 27 Mar 2005 10:35:09 -0800, Grant wrote:

> If I'm understanding it correctly, FEATURES="buildpkg" sounds less
> reliable for failed upgrade recovery.  If you want to roll back to a
> previous version of a package, you're going to end up with what was
> originally installed, not what was working on your system right before
> the upgrade, right?

Wrong. buildpkg builds a binary package for each package before installing
it, so you have the current version and all previous versions, since you
enabled buildpkg, in PKGDIR. It means you can rol back as far as you like.


-- 
Neil Bothwick

Things are more like they are today than they ever have been before.


pgpLBkx01WBhl.pgp
Description: PGP signature


Re: [gentoo-user] quickpkg

2005-03-27 Thread Nick Rout
On Sun, 2005-03-27 at 10:35 -0800, Grant wrote:
> > > A little while ago Neil turned me on to quickpkg.  It sounds like a
> > > great way to protect yourself from the new package blues.  Is anyone
> > > using it like that?  What would be the best way to assure that your
> > > system always has a backup copy of your current version of a package
> > > available before emerging a new one?
> > 
> > A more reliable method, assuming you have the drive space, is to add
> > buildpkg to FEATURES in make.conf. Then emerge will automatically build a
> > package when installing a package. It also means the package is verified,
> > because ebuild builds it then installs from the package it just built, not
> > the files in $PORTAGE_TMPDIR.
> 
> If I'm understanding it correctly, FEATURES="buildpkg" sounds less
> reliable for failed upgrade recovery.  If you want to roll back to a
> previous version of a package, you're going to end up with what was
> originally installed, not what was working on your system right before
> the upgrade, right?

wrong, as the package name contains the version information - eg
xorg-x11-6.8.2-r1.tbz2 not xorg-x11.tbz2

so unless you are constantly re-installing the same package with
different use flags or cflags you should get a different binary pavckage
name each time.


> 
> Also, I tried to use quickpkg to protect me from any problems
> upgrading xorg and I ended up totally screwed.  I quickpackaged my
> installed xorg, emerged the latest xorg, it wouldn't start, I tried to
> 'emerge -K xorg-x11', it said it was blocked by xorg-x11, I unmerged
> xorg-x11, it still said it was blocked, I tried to unmerge xorg-x11
> again and it said it wasn't installed.  It does sound like a portage
> problem instead of a quickpkg problem.  I've finally gotten xorg
> working again thanks to a closed bug record, and let me tell you this:
> 
> 1. don't emerge hardened xorg without dlloader
> 2. lynx doesn't work with gmail (predictable)
> 
> - Grant
> 
> > Neil Bothwick
> --
> gentoo-user@gentoo.org mailing list
> 
-- 
Nick Rout <[EMAIL PROTECTED]>

--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] quickpkg

2005-03-27 Thread Grant
> > A little while ago Neil turned me on to quickpkg.  It sounds like a
> > great way to protect yourself from the new package blues.  Is anyone
> > using it like that?  What would be the best way to assure that your
> > system always has a backup copy of your current version of a package
> > available before emerging a new one?
> 
> A more reliable method, assuming you have the drive space, is to add
> buildpkg to FEATURES in make.conf. Then emerge will automatically build a
> package when installing a package. It also means the package is verified,
> because ebuild builds it then installs from the package it just built, not
> the files in $PORTAGE_TMPDIR.

If I'm understanding it correctly, FEATURES="buildpkg" sounds less
reliable for failed upgrade recovery.  If you want to roll back to a
previous version of a package, you're going to end up with what was
originally installed, not what was working on your system right before
the upgrade, right?

Also, I tried to use quickpkg to protect me from any problems
upgrading xorg and I ended up totally screwed.  I quickpackaged my
installed xorg, emerged the latest xorg, it wouldn't start, I tried to
'emerge -K xorg-x11', it said it was blocked by xorg-x11, I unmerged
xorg-x11, it still said it was blocked, I tried to unmerge xorg-x11
again and it said it wasn't installed.  It does sound like a portage
problem instead of a quickpkg problem.  I've finally gotten xorg
working again thanks to a closed bug record, and let me tell you this:

1. don't emerge hardened xorg without dlloader
2. lynx doesn't work with gmail (predictable)

- Grant

> Neil Bothwick
--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] quickpkg

2005-03-25 Thread Neil Bothwick
On Thu, 24 Mar 2005 17:13:09 -0800, Grant wrote:

> A little while ago Neil turned me on to quickpkg.  It sounds like a
> great way to protect yourself from the new package blues.  Is anyone
> using it like that?  What would be the best way to assure that your
> system always has a backup copy of your current version of a package
> available before emerging a new one?

A more reliable method, assuming you have the drive space, is to add
buildpkg to FEATURES in make.conf. Then emerge will automatically build a
package when installing a package. It also means the package is verified,
because ebuild builds it then installs from the package it just built, not
the files in $PORTAGE_TMPDIR.


-- 
Neil Bothwick

"Bother", said Pooh, as he crossed the event horizon.


pgpU1jmLvTbwT.pgp
Description: PGP signature


Re: [gentoo-user] quickpkg

2005-03-24 Thread Ow Mun Heng
On Thu, 2005-03-24 at 17:13 -0800, Grant wrote:
> A little while ago Neil
Who's Neil? :-D

>  turned me on to quickpkg.  It sounds like a
> great way to protect yourself from the new package blues.  

And you mean upgrades that didn't go smoothly??

> Is anyone
> using it like that?  What would be the best way to assure that your
> system always has a backup copy of your current version of a package
> available before emerging a new one?  

You can do this by always making a copy of the packages you emerge.

Use the "buildpkg" directive in your make.conf's 
FEATURE="buildpkg"

> Are there any types of packages
> or situations where this method of upgrade protection would fail?

Not that I know of. It's saved my hide a few times and not having to
wait 4 hours for xorg to rebuild is nice :-)

> - Grant
> --
> gentoo-user@gentoo.org mailing list

-- 
Ow Mun Heng
Gentoo/Linux on DELL D600 1.4Ghz 
98% Microsoft(tm) Free!! 
Neuromancer 10:54:51 up 1 day, 1:32, 5 users, load average: 0.52, 0.34,
0.30 


--
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] quickpkg and kde

2003-12-14 Thread Tom Hosiawa
> On Monday 15 December 2003 12:24, Tom Hosiawa wrote:
> > I want to use quickpkg to build kde on my laptop and then install it on
> > my desktop using the binary package. The problem is kde is an eclass, so
> > how do I determine all the packages I need to build for kde?
> 
> kde is actually a package, but it doesn't install anything itself. It only 
> depends on other packages. Here is an excerpt from 
> kde-base/kde/kde-3.1.4.ebuild:
> RDEPEND="`echo 
> ~kde-base/kde{libs,base,addons,admin,artwork,edu,games,graphics,multimedia,network,pim,toys,utils}-${PV}`"
> 
> Thus the dependencies are:
> kde-base/kdeaddons
> kde-base/kdeadmin
> kde-base/kdeartwork
> kde-base/kdebase
> kde-base/kdeedu
> kde-base/kdegames
> kde-base/kdegraphics
> kde-base/kdelibs
> kde-base/kdemultimedia
> kde-base/kdenetwork
> kde-base/kdepim
> kde-base/kdetoys
> kde-base/kdeutils
> 
> You can do the same to check other kde versions.

Thanks

Tom


--
[EMAIL PROTECTED] mailing list



Re: [gentoo-user] quickpkg and kde

2003-12-14 Thread Jason Stubbs
On Monday 15 December 2003 12:24, Tom Hosiawa wrote:
> I want to use quickpkg to build kde on my laptop and then install it on
> my desktop using the binary package. The problem is kde is an eclass, so
> how do I determine all the packages I need to build for kde?

kde is actually a package, but it doesn't install anything itself. It only 
depends on other packages. Here is an excerpt from 
kde-base/kde/kde-3.1.4.ebuild:
RDEPEND="`echo 
~kde-base/kde{libs,base,addons,admin,artwork,edu,games,graphics,multimedia,network,pim,toys,utils}-${PV}`"

Thus the dependencies are:
kde-base/kdeaddons
kde-base/kdeadmin
kde-base/kdeartwork
kde-base/kdebase
kde-base/kdeedu
kde-base/kdegames
kde-base/kdegraphics
kde-base/kdelibs
kde-base/kdemultimedia
kde-base/kdenetwork
kde-base/kdepim
kde-base/kdetoys
kde-base/kdeutils

You can do the same to check other kde versions.

-- 
Regards,
Jason Stubbs

--
[EMAIL PROTECTED] mailing list