[gentoo-portage-dev] /etc/portage/profile/{pmask,arch.list, categories}
Apparently these weren't working ( not being read in ) due to a lack of /etc/portage/profile being in Locations in config in portage.py I split a patch for hte issue by simply adding the extra location and fixing the odd grabfile_package calls. It seems grabfile package was stripping the - so it wouldn't nuke existing entries in the pmask file. Comments welcome as usual. Alec Warner (antarus) pgpe9C7P88z5H.pgp Description: PGP signature
Re: [gentoo-portage-dev] Package moves in overlays
Yeah, Sorry about the double posting, patrick told me about a gmail feature that means you never see your own posts... I agree that the updates should only affect that individual tree. Whilst I can imagine cases where a move in the main tree should affect overlay trees (such as recategorizing some net-misc ebuilds into a net-proxy category), that could at least be emulated with a per-tree move directive fairly easily. It sounds as though the answer is that there currently no way to do these kinds of moves, so what's the next step? Should I try and hack up a version to deal with updates on a per tree basis? Is it actively being developed and I'm just unaware of it? What can I do to help get this feature into a future version of portage? It would be very useful to have, because at the moment network administrator's can't quite use overlays as a software management mechanism... Thanks for you time, Mike 5:) -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Fwd: /etc/portage/profile/{pmask,arch.list, categories}
My Apologies, KMail died, and when I restarted it it had the mail but stripped
the attachment ;)
-- Forwarded Message --
Subject: /etc/portage/profile/{pmask,arch.list, categories}
Date: Monday 09 January 2006 09:59
From: Alec Warner [EMAIL PROTECTED]
To: gentoo-portage-dev@gentoo.org
Apparently these weren't working ( not being read in ) due to a lack
of /etc/portage/profile being in Locations in config in portage.py
I split a patch for hte issue by simply adding the extra location and fixing
the odd grabfile_package calls. It seems grabfile package was stripping the
- so it wouldn't nuke existing entries in the pmask file.
Comments welcome as usual.
Alec Warner (antarus)
---
--- portage.py.ferringb 2006-01-05 03:55:17.169455112 -0500
+++ portage.py 2006-01-09 09:49:00.743795432 -0500
@@ -1108,7 +1108,7 @@
self.pkeywordsdict = {}
self.punmaskdict = {}
else:
-locations = [self[PORTDIR] + /profiles, USER_CONFIG_PATH]
+locations = [self[PORTDIR] + /profiles, USER_CONFIG_PATH,USER_CONFIG_PATH+/profile]
for ov in self[PORTDIR_OVERLAY].split():
ov = os.path.normpath(ov)
if os.path.isdir(ov+/profiles):
@@ -1165,13 +1165,16 @@
self.loadVirtuals('/')
#package.mask
- pkgmasklines = [grabfile_package(os.path.join(x, package.mask)) for x in self.profiles]
+
+ pkgmasklines = [grabfile(os.path.join(x, package.mask)) for x in self.profiles]
for l in locations:
-pkgmasklines.append(grabfile_package(l+os.path.sep+package.mask, recursive=1))
+pkgmasklines.append(grabfile(x+os.path.sep+package.mask, recursive=1))
pkgmasklines = stack_lists(pkgmasklines, incremental=1)
self.pmaskdict = {}
for x in pkgmasklines:
+if not isvalidatom(x):
+ writemsg(!!! Invalid atom %s in package.mask % x )
mycatpkg=dep_getkey(x)
if self.pmaskdict.has_key(mycatpkg):
self.pmaskdict[mycatpkg].append(x)
pgpP0rR57b22x.pgp
Description: PGP signature
Re: [gentoo-portage-dev] Package moves in overlays
Mike Auty wrote: Yeah, I agree that the updates should only affect that individual tree. Whilst I can imagine cases where a move in the main tree should affect overlay trees (such as recategorizing some net-misc ebuilds into a net-proxy category), that could at least be emulated with a per-tree move directive fairly easily. It sounds as though the answer is that there currently no way to do these kinds of moves, so what's the next step? Should I try and hack up a version to deal with updates on a per tree basis? Is it actively being developed and I'm just unaware of it? What can I do to help get this feature into a future version of portage? It would be very useful to have, because at the moment network administrator's can't quite use overlays as a software management mechanism... Thanks for you time, As currently vdb/pkgdir don't track the repo where a package comes from it's not possible to do it in a proper way (those are affected by moves, not the repositories themselves). Marius -- gentoo-portage-dev@gentoo.org mailing list
