Re: [gentoo-portage-dev] Re: Plausible idea for GLEP 19?

[Mikey]

On Monday 23 January 2006 04:56, Patrick Börjesson spammed:

 The problem with your reasoning is that portage only reports the
 highest upgrade (from it's point of view). So if you have package
 A-1.0 installed and two possible upgrades, say A-1.0-s1 and A-1.1, then
 portage will chose the highest of the two. So the output from that

 command would be:
 | These are the packages that I would merge, in reverse order:
 |
 | Calculating world dependencies ...done!
 | [ebuild U ] the-cat/A-1.1 [1.0] ..

 It will not output the following:
 | These are the packages that I would merge, in reverse order:
 |
 | Calculating world dependencies ...done!
 | [ebuild U ] the-cat/A-1.0-s1 [1.0] ..

 So you _will_ miss upgrades if you only filter the output of emerge in
 your solution and expect to get all security related upgrades relating
 to the package you're using.

That is _exactly_ how it is intended to work.  Normal users will get A-1.1 
when they run emerge -u.  Users with a need for stability will only see 
A-1.0-s1, and only if it is available for A-1.0.

Perhaps I should have named it hotfix instead of glsa-only.  This 
feature is targeted towards environments that prioritize stability slightly 
over security.  Often it is not an option to upgrade to the next version of 
something until it has been regression tested, various apps have been 
migrated/ported, etc...

My patches alone don't make this possible, but they at least provide a 
framework for it to happen in the future.  Users who need backported 
security fixes could band together for the major apps and do the work, the 
-s packages could be distributed via overlays (so as not to interfere with 
old versions of portage).



pgpnO2YBP4w6k.pgp
Description: PGP signature

Re: [gentoo-portage-dev] Re: Plausible idea for GLEP 19?

[Mikey]

On Monday 23 January 2006 12:46, Marius Mauch spammed:

  That is _exactly_ how it is intended to work.  Normal users will
  get A-1.1 when they run emerge -u.  Users with a need for stability
  will only see A-1.0-s1, and only if it is available for A-1.0.

 And for that you have to hack the resolver so it only sees your -sX
 updates.

Um, nope.

+   if myaction==glsa-only:
+   pkglist = mydepgraph.altlistglsa()

Leads to:

+   def altlistglsa(self):
+   retlist=[]
+   for y in self.altlist():
^^^
+   psplit=portage.pkgsplit(y[2])
+   myrev=psplit[-1]
+   myrevtype=myrev[0]
+   if myrevtype==s:
+   retlist.append(y)
+   return retlist
+

No touching the resolver, only filter output.  The filter code is not 
complete yet - I still need to compare current version -vs- new version.  

The only other place I am touching anything is pkgsplit in portage.py:

-   if len(myrev) and myrev[0]==r:
+   if len(myrev) and myrev[0] in [r,s]:


pgp5tCd4M7LIo.pgp
Description: PGP signature

Re: [gentoo-portage-dev] Plausible idea for GLEP 19?

[Mikey]

On Saturday 21 January 2006 22:39, Marius Mauch wrote:

 Check the archives for gentoo-dev and gentoo-server, several
 implementation plans have been presented in the not-so-distant past.
 However everyone seems to have a slightly different goal he wants to
 achieve, so maybe the best would be for people to make their goals very
 clear.

I have checked the archives of gentoo-dev, gentoo-server, and have 
researched everything I can find about glep 19.  I have come to the 
conclusion that those projects are the /dev/null of gentoo projects.  
Post a request somewhere - hey, check out glep 19, wink wink.

Let me make my goal clear.  I would like to see some simple features added 
that does not require disruption of current usage, future plans, or require 
massive changes.  I am not interested in reviving dead projects or loft 
goals.

 No point, would rather add a RSYNC_OPTS var finally instead, which gives
 the same functionality (and much more).

If that would work, great.  Not sure how rsync handles ordering/precedence 
of conflicting options, now or in the future.  Also not sure how the 
environment may or may not be manipulated in the future by emerge itself.  
Right now the options are hard-coded into emerge, the simplest place to 
change it in my mind is right there where it happens...

  2) Implement a new revision numbering scheme for ebuilds, -sX.  Similar
  to -rX, but for glsa updates only.  It could be an abbreviation for
  sticky, security, or stable, whatever you want.
 
  For example if I am currently running mysql-4.0.25, the only candidate
  an emerge -u would consider would be mysql-4.0.25-s1, mysql-4.0.25-s2,
  etc In other words, emerge considers only -sX in its upgrade
  calculations, instead of -rX, and only considers the same version.

 No way. No visible benefit (you know about glep 14 / glsacheck, right?)
 and tons of issues (redundant ebuilds, ordering screwups, ...)

Yes, I am aware of glsacheck.  How long has it been in testing?  Every time 
I try it I get inconsistent results.  Something about WARNING: This tool 
is completely new and not very tested, so it should not be
used on production systems.  kind of makes me hesitate to use it.

As far as redundant ebuilds and ordering screwups.  If you change line 3173 
of portage.py to:

if len(myrev) and myrev[0] in [r,s]:

Everything works quite well actually.  The s is sorted after the r, so -s7 
would install after -r6 or instead of -r7.  It is actually a much simpler 
solution than glsa, could be introduced immediately to the portage tree, 
and use of it could be optional.  People could use them in their own 
overlays, backport their own security fixes.

 No chance you get people to agree on something that will bloat the tree
 without any real benefit. Mind that we already revbump packages for
 security updates.

Packages are not only revbumped for security updates.  I have not researched 
it much, but I would be willing to be the vast majority of revbumps are 
_rarely_ for security updates.  Most of the time glsas suggest to bump up 
to the next version of the package, not revision...  There is also no way 
to distinguish between a revbump that alters the package via a revbump that 
is only because a glibc has just been marked stable for another 
architecture, for example.

 No, this includes way too many changes to core functions (version
 comparison, resolver) with no visible benefit (from my POV). In case you
 haven't done so already take a good look at glep 14 and glsa-check
 (which implements the least-invasive update algorithm you seem to be
 after).

I am happy to see that you state that the no visible benefit is limited to 
your POV.  Glep 14 (glsa-check) is a fine idea, a fine proposal.  The only 
problem is that it appears as though it is never going to happen, at least 
not the final goal - to get integrated into portage.

I like my idea better.  It is a very simple change that could be introduced 
immediately with little or no ill effect.  Functionally, that one line 
patch I posted above would work as far as I can tell.  It instantly creates 
a framework for backporting security fixes (without affecting current 
usage), glsa does not.  GLSA updates would then become a fairly simple 
matter - emerge -Du world, filter out all non -sX packages.  Extend the 
idea further and people who desire could filter syncs to just retrieve 
*-sX.ebuild and your load on the mirrors has just lightened, not grown..


pgpIrZttezczC.pgp
Description: PGP signature

Re: [gentoo-portage-dev] Plausible idea for GLEP 19?

[Mikey]

On Sunday 22 January 2006 13:02, Marius Mauch wrote:

 Well, posting YAIP (yet another implementation plan) won't really help
 either.

Correct, plans never seem to go anywhere in regards to this...

 Don't see the goal here, just the constraints. Are you after a
 non-moving tree, a tree with just security fixes, visibility filters in
 portage, a new `emerge moo` graphics, ... ?

The existing tree with additional functionality.  Implemented via a new 
revision type.

   No point, would rather add a RSYNC_OPTS var finally instead, which
   gives the same functionality (and much more).

 Yeah, RSYNC_OPTIONS would remove all that hardcoded stuff and put it in
 make.globals instead.

From make.globals:

#*
#**  DO NOT EDIT THIS FILE  **
# ***
#  CHANGES TO make.conf *OVERRIDE* THIS FILE 
# ***
# ** Incremental Variables Accumulate Across Files **
# **  USE, CONFIG_*, and FEATURES are incremental  **
# ***

 I removed the warning in gentoolkit-2.1 (wanted to do that for quite
 some, just didn't get around to do it). What kind of inconsistent
 results are you speaking of?

http://www.gentoo.org/proj/en/portage/glsa-integration.xml, section on known 
problems.

The plan is nice.  It does not, however, address the needs of some users to 
have a STABLE system as well.  Some users can't willy nilly upgrade to the 
next version of a package because they might have requirements to stay at 
the same version.  Through something as simple as adding a new revision 
specifier, a framework can be in place to backport security fixes or ONLY 
apply revisions that are security related...

 Still has issues as this allows for multiple equal versions to exist
 (as -rX == -sX). And no, it could not be used immideately in the tree

In this case the s is seen as more recent (I have already tested it).  If 
there is a -r5 and a -s5 package, the -s5 package is seen as the most 
recent.  The depgraph must be sorting alphabetically.  You could, in 
effect, migrate towards having revbumps that only add security fixes as -s.  
Revbumps that are trivial (becoming stable in another arch) could continue 
being -r.  Either way, if they were exact copies of the same ebuild, no 
harm, no foul.

 as unaware portage versions would fail with interesting errors (see
 glep 45 for background info), same reason the versioning extensions in
 2.1 can't be used yet (even if 2.1 would be stable). And I'm quite sure
 that if this would be used in the tree we'd hit versioning screwups
 sooner or later (-sX - -rX+1 - -rX+2 - -sX+1).

Damn you, damn you all to hell!

 I didn't claim that all/the majority of revbumps are security related.
 And there is a way to distinguish the different kind of revbumps: read
 the changelog.

Hah hah, funny.

 Well, it only needs a way to feed a set of nodes into the dep
 resolver. But that in turn is quite a task as the dep resolver code is
 nasty.

I have looked at the dep resolver and don't want to go near it with a 10 
foot pole.  I only want to do the functional equivalent of filtering out 
anything but *-sX$ (pseudo regex) during the final doemerge or when 
displaying in case of --pretend.

 What functionality does it actually add? The changes you described so
 far just allow multiple letters as revision prefixes. The main thing of
 your proposal was probably to limit updates to -s updates, and that's a
 tricky goal.

It enables ebuild maintainers to backport security patches.  It allows them 
to fix security problems that are not glsa alerts.  It does not require the 
use of a new tool or integration of glsa into portage.  It allows users to 
distinguish between revbumps of a trivial nature and revbumps of a security 
nature.

 Wow, allowing multiple letters for revision prefixes counts as creating
 a framework theses days ;)

Yes, I believe it can.  The same way -r is a framework for updating existing 
packages.

 Again, you haven't touched the resolver yet, so you're not filtering
 anything out so far. And that is the crucial part here as far as I
 understand your proposal.

Working on it...  What a nightmare.  I don't want to touch the resolver 
code, only call a different altlist to pass to mydepgraph.merge() or 
mydepgraph.display() that filters out anything but -sX packages.  I am also 
learning python as I go.

Something along the lines of:

emerge glsa-updates (new action)
internally do an emerge -Du world to get the depgraph
filter final call to act only on -sX packages

Like you said, that appears to be the not-quite-so-simple part of my master 
plan :)


pgp07rM7AJLqd.pgp
Description: PGP signature

Re: [gentoo-portage-dev] Re: Plausible idea for GLEP 19?

[Mikey]

On Sunday 22 January 2006 16:56, Marius Mauch wrote:

   That's not really what you want.
   -s updates might (will) be overlaid with version or revision bumps
   from time to time, for this to be of any use it has to happen at the
   resolver level (visiblity filter).
 
  Normal emerges would take -s2 over -r1 or -s1.  The change is
  transparent when not in glsa-only mode.

 You didn't understand what I said. If you just play around with the
 output info you'll miss updates.

How will I miss updates?  Standard actions (system world) or myfiles would 
work the exact same as they do now, they just consider a new revbump 
specifier in the digraph calculation.

The non-standard action that I am proposing, call it emerge glsa-only, 
would take the output from emerge -Du world and filter out anything from 
the resulting package list except for -s packages.  I will only miss 
updates that are not strictly security related.  If there is no 
security-only related update, i.e. I have to upgrade to the next version, 
glsa-check will report it and I will have to manually update.  

I have attached rough proof of concept patches, the only thing missing is 
the version matching check.  I still have to figure out the best way to 
compare the currently installed version -vs- the update version...

 Sorry? What prevents anyone from doing backports? It's as safe as your
 idea for both automatic and manual (unless you assume that all security
 updates will only ever be a -sX bump), and the last two are just random
 comments that don't mean anything.

Bad choice of words.  Neither method prevents anyone from doing backports, 
but one method allows you to continue _only_ installing backports (if 
available) instead of version bumps.

For example, for some bizarro reason, I have a requirement to continue 
running mysql-4.0.25.  A glsa is published, requiring an upgrade to 
mysql-4.1.x.  The mysql ebuild maintainer no longer maintains the 4.0.25 
tree, but debian has a patch that fix the vulnerability.  For users in my 
situation, a new ebuild can be created (mysql-4.0.25-s3) with the new 
patch, I can continue on safely using my required version of mysql.  Users 
without such stability requirements can just emerge -u and get the latest 
stable version of mysql for their arch.  Everybody is happy?

 Anyway, showed you why it won't work and why it won't get implemented,
 so rather pointless to continue this.

The only show stoppers you mentioned is the installation of s5 with all of 
r4's updates that were not desired and the older emerges choking on weird 
names.  

The first problem could be worked around by having the normal actions 
(system, world, myfiles) not consider the new s extension in depgraph 
calculations.  Even without this workaround, it still might be a worthy 
feature.  I don't know about the 2nd problem, I would have to test to see 
what happens...

Thanks for letting me ramble anyway.
--- emerge.orig	2006-01-22 17:09:36.0 -0600
+++ emerge	2006-01-22 17:20:02.0 -0600
@@ -305,8 +305,8 @@
 
 
 
-if (myaction in [world, system]) and myfiles:
-	print emerge: please specify a package class (\world\ or \system\) or individual packages, but not both.
+if (myaction in [glsa-only, world, system]) and myfiles:
+	print emerge: please specify a package class (\glsa-only\ \world\ or \system\) or individual packages, but not both.
 	sys.exit(1)
 
 for x in myfiles:
@@ -338,6 +338,13 @@
 		myopts.append(--search)
 	myaction = search
 
+# Always add --deep and --update if myaction is glsa-only
+if myaction==glsa-only:
+	if --deep not in myopts:
+		myopts.append(--deep)
+	if --update not in myopts:
+		myopts.append(--update)
+
 # Always try and fetch binary packages if FEATURES=getbinpkg
 if (getbinpkg in portage.features):
 	myopts.append(--getbinpkg)
@@ -1390,6 +1397,16 @@
 retlist.append(y)
 		return retlist
 
+	def altlistglsa(self):
+		retlist=[]
+		for y in self.altlist():
+			psplit=portage.pkgsplit(y[2])
+			myrev=psplit[-1]
+			myrevtype=myrev[0]
+			if myrevtype==s:
+retlist.append(y)
+		return retlist
+
 	def xcreate(self,mode=system):
 		global syslist
 		if mode==system:
@@ -3204,7 +3221,10 @@
 		if (--resume in myopts):
 			mydepgraph.display(portage.mtimedb[resume][mergelist])
 		else:
-			mydepgraph.display(mydepgraph.altlist())
+			if myaction==glsa-only:
+mydepgraph.display(mydepgraph.altlistglsa())
+			else:
+mydepgraph.display(mydepgraph.altlist())
 	else:
 		if (--buildpkgonly in myopts):
 			if not mydepgraph.digraph.hasallzeros():
@@ -3231,8 +3251,10 @@
 	if pkg[0] != blocks:
 		pkglist.append(pkg)
 			else:
-pkglist = mydepgraph.altlist()
-			mydepgraph.merge(pkglist)
+if myaction==glsa-only:
+	pkglist = mydepgraph.altlistglsa()
+else:
+	mydepgraph.merge(pkglist)
 
 		if portage.mtimedb.has_key(resume):
 			del portage.mtimedb[resume]
--- portage.py.orig	2006-01-22 17:10:01.0 -0600
+++ portage.py	2006-01-22 17:16:53.0 -0600
@@ 

Re: [gentoo-portage-dev] Re: Plausible idea for GLEP 19?

[Mikey]

Oops, wrong patch.  Here is the correct one...
--- emerge.orig	2006-01-22 18:31:34.0 -0600
+++ emerge	2006-01-22 18:30:01.0 -0600
@@ -162,6 +162,7 @@
 params=[selective, deep, self, recurse, empty]
 actions=[
 clean, config, depclean,
+glsa-only,
 info,   inject,   metadata,
 prune, regen,  rsync, search,
 sync,  system, unmerge,  world,
@@ -253,7 +254,7 @@
 print
 x=--sync
 			if myaction:
-if myaction not in [system, world]:
+if myaction not in [glsa-only, system, world]:
 	myaction=--+myaction
 print
 print red(!!!)+green( Multiple actions requested... Please choose one only.)
@@ -265,7 +266,7 @@
 			print !!! Error:,x,is an invalid option.
 			sys.exit(1)
 	elif (not myaction) and (x in actions):
-		if x not in [system, world]:
+		if x not in [glsa-only, system, world]:
 			#print red(*** Deprecated use of action '+x+')
 			if x==rsync:
 # emerge rsync
@@ -305,8 +306,8 @@
 
 
 
-if (myaction in [world, system]) and myfiles:
-	print emerge: please specify a package class (\world\ or \system\) or individual packages, but not both.
+if (myaction in [glsa-only, world, system]) and myfiles:
+	print emerge: please specify a package class (\glsa-only\ \world\ or \system\) or individual packages, but not both.
 	sys.exit(1)
 
 for x in myfiles:
@@ -338,6 +339,13 @@
 		myopts.append(--search)
 	myaction = search
 
+# Always add --deep and --update if myaction is glsa-only
+if myaction==glsa-only:
+	if --deep not in myopts:
+		myopts.append(--deep)
+	if --update not in myopts:
+		myopts.append(--update)
+
 # Always try and fetch binary packages if FEATURES=getbinpkg
 if (getbinpkg in portage.features):
 	myopts.append(--getbinpkg)
@@ -1390,6 +1398,16 @@
 retlist.append(y)
 		return retlist
 
+	def altlistglsa(self):
+		retlist=[]
+		for y in self.altlist():
+			psplit=portage.pkgsplit(y[2])
+			myrev=psplit[-1]
+			myrevtype=myrev[0]
+			if myrevtype==s:
+retlist.append(y)
+		return retlist
+
 	def xcreate(self,mode=system):
 		global syslist
 		if mode==system:
@@ -3134,7 +3152,7 @@
 			sys.exit(0)
 
 		mydepgraph=depgraph(myaction,myopts)
-		if myaction in [system,world]:
+		if myaction in [glsa-only,system,world]:
 			print Calculating,myaction,dependencies  ,
 			sys.stdout.flush()
 			if not mydepgraph.xcreate(myaction):
@@ -3204,7 +3222,10 @@
 		if (--resume in myopts):
 			mydepgraph.display(portage.mtimedb[resume][mergelist])
 		else:
-			mydepgraph.display(mydepgraph.altlist())
+			if myaction==glsa-only:
+mydepgraph.display(mydepgraph.altlistglsa())
+			else:
+mydepgraph.display(mydepgraph.altlist())
 	else:
 		if (--buildpkgonly in myopts):
 			if not mydepgraph.digraph.hasallzeros():
@@ -3231,7 +3252,10 @@
 	if pkg[0] != blocks:
 		pkglist.append(pkg)
 			else:
-pkglist = mydepgraph.altlist()
+if myaction==glsa-only:
+	pkglist = mydepgraph.altlistglsa()
+else:
+	pkglist = mydepgraph.altlist()
 			mydepgraph.merge(pkglist)
 
 		if portage.mtimedb.has_key(resume):


pgp0vWA3sIH2H.pgp
Description: PGP signature

[gentoo-portage-dev] Re: Plausible idea for GLEP 19?

[Mikey]

Attached is a patch that adds a new option when syncing, emerge --sync
--no-sync-delete.  It simply removes the --force --delete --delete-after
rsync arguments.  This will enable users to only add/update their local
portage trees, which is not really possible using excludes...  More
importantly if they don't want ebuilds disappearing that they have
dependencies on, custom profiles, etc... they have the option of hanging on
to them...

Would it be possible to get a feature like this implemented?  If so I would
also be glad to submit a patch for emerge-webrsync and the man pages...diff -ur portage.orig/bin/emerge portage/bin/emerge
--- portage.orig/bin/emerge	2006-01-21 15:35:53.0 -0600
+++ portage/bin/emerge	2006-01-21 15:43:31.0 -0600
@@ -177,6 +177,7 @@
 --getbinpkg,--getbinpkgonly,
 --help, --noconfmem,
 --newuse,   --nocolor,
+--no-sync-delete,
 --nodeps,   --noreplace,
 --nospinner,--oneshot,
 --onlydeps, --pretend,
@@ -2428,10 +2429,7 @@
 			--perms,# Preserve permissions
 			--times,# Preserive mod times
 			--compress, # Compress the data transmitted
-			--force,# Force deletion on non-empty dirs
 			--whole-file,   # Don't do block transfers, only entire files
-			--delete,   # Delete files that aren't in the master tree
-			--delete-after, # Delete only after everything else is done
 			--stats,# Show final statistics about what was transfered
   --timeout=+str(mytimeout), # IO timeout if not done in X seconds
 			--exclude='/distfiles',   # Exclude distfiles from consideration
@@ -2439,6 +2437,11 @@
 			--exclude='/packages',# Exclude packages  from consideration
 		]

+		if --no-sync-delete not in myopts:
+			rsync_flags.append(--force) # Force deletion on non-empty dirs
+			rsync_flags.append(--delete)# Delete files that aren't in the master tree
+			rsync_flags.append(--delete-after)  # Delete only after everything else is done
+
 		if --quiet in myopts:
 			rsync_flags.append(--quiet)# Shut up a lot
 		else:
@@ -2530,8 +2533,12 @@
 		print
 		sys.exit(0)
 emergelog( starting rsync with +dosyncuri)
+if --no-sync-delete in myopts:
+	emergelog( --no-sync-delete detected)
 if --quiet not in myopts:
 	print  starting rsync with +dosyncuri+...
+	if --no-sync-delete in myopts:
+		print  --no-sync-delete detected
 			else:
 emergelog( Starting retry %d of %d with %s % (retries,maxretries,dosyncuri))
 print \n\n Starting retry %d of %d with %s % (retries,maxretries,dosyncuri)
diff -ur portage.orig/pym/emergehelp.py portage/pym/emergehelp.py
--- portage.orig/pym/emergehelp.py	2006-01-21 15:35:53.0 -0600
+++ portage/pym/emergehelp.py	2006-01-21 15:45:27.0 -0600
@@ -12,7 +12,7 @@
 	print bold(Usage:)
 	print+turquoise(emerge)+ [ +green(options)+ ] [ +green(action)+ ] [ +turquoise(ebuildfile)+ | +turquoise(tbz2file)+ | +turquoise(dependency)+ ] [ ... ]
 	print+turquoise(emerge)+ [ +green(options)+ ] [ +green(action)+ ]  +turquoise(system)+ | +turquoise(world)+ 
-	print+turquoise(emerge)+  +turquoise(--sync)+ | +turquoise(--metadata)+ | +turquoise(--info)+ 
+	print+turquoise(emerge)+  +turquoise(--sync)+ [ +green(--no-sync-delete)+ ] | +turquoise(--metadata)+ | +turquoise(--info)+ 
 	print+turquoise(emerge)+ +turquoise(--resume)+ [ +green(--pretend)+ | +green(--ask)+ | +green(--skipfirst)+ ]
 	print+turquoise(emerge)+ +turquoise(--help)+ [ +green(system)+ | +green(config)+ | +green(sync)+ ] 
 	print bold(Options:)+ +green(-)+[+green(abcCdDefhikKlnNoOpPsSuUvV)+] [+green(--oneshot)+] [+green(--newuse)+] [+green(--noconfmem)+]
@@ -216,6 +216,10 @@
 		print+green(--nospinner)
 		print   Disables the spinner regardless of terminal type.
 		print
+		print+green(--no-sync-delete)
+		print   Do not delete any files from the local portage tree when
+		print   using +bold(emerge --sync)+.
+		print
 		print+green(--oneshot)
 		print   Emerge as normal, but don't add packages to the world profile.
 		print   This package will only be updated if it is depended upon by

[gentoo-portage-dev] Plausible idea for GLEP 19?

[Mikey]

I have been emailing the published addresses for GLEP 19 for 2 months now 
with no success.  I am very interested in any ideas or projects that might 
help gentoo be more server friendly, in an enterprise environment, for 
lack of a better term.  

I have an idea towards stabilizing portage for production environments, 
but I am not knowledgeable enough about portage to know if it would even be 
plausible.  If this is the wrong place to ask this, please feel free to 
point me in a better direction.

Basically, add a new value for FEATURES.  For lack of a better name, call 
it sticky.

FEATURES=sticky

If this flag is present in make.conf:

1) emerge --sync does only updates, not deletes (don't ditch old ebuilds).

2) Implement a new revision numbering scheme for ebuilds, -sX.  Similar to 
-rX, but for glsa updates only.  It could be an abbreviation for sticky, 
security, or stable, whatever you want.  

For example if I am currently running mysql-4.0.25, the only candidate an 
emerge -u would consider would be mysql-4.0.25-s1, mysql-4.0.25-s2, etc  
In other words, emerge considers only -sX in its upgrade calculations, 
instead of -rX, and only considers the same version.

3) Package maintainers could create duplicate ebuilds for security-only 
related revisions to packages, some other team could maintain them, this be 
somehow automated, or this could be left up to the users to maintain 
through their own overlays.  My idea is fuzzy here...

4) In cases where a vulnerability exists that can only be addressed by 
bumping up to the next version, leave it up to the user to upgrade to it 
manually (FEATURES=-sticky emerge -u mysql).

Plausible?


pgptqwvjvxyLi.pgp
Description: PGP signature

[gentoo-portage-dev] Custom eclass question

[Mikey]

I recently posted a question in the Portage  Programming forum and was told 
that this mailing list might be the place to go.  Any help would be greatly 
appreciated.

I have a custom in-house web based source code/packaging repository system 
that I need to integrate into ebuilds. It is kind of like a funky cvs 
system.  Source code and packages are all viewed or downloaded via a 
browser.

For example, to retrieve a gzipped tarball of a package named mypackage 
from the repository looks like:

http://codeserver.wherever.net/pman/package_ids.php?action=packageid=10105

On any standard browser (konqueror, IE, firefox) this would retrieve a file 
named mypackage.tar.gz.

Here is where my problem starts, and why I believe a custom eclass might be 
my best route.

The utility that fetches packages via emerge mangles the resulting file 
name, as well as wget (does emerge use wget?). When fetching the above url, 
emerge or wget saves the file as package_ids.php?action=packageid=10105. 
This of course throws a wrench into my use of custom ebuilds :)

Currently I route around the problem with a stupid hack in my ebuilds: 

##mypackage-20051006.ebuild
#MY_P=mypackage.tar.gz
#DESCRIPTION=My example package
#HOMEPAGE=http://codeserver.wherever.net/pman/package_ids.php?action=packageid=1015;
#SRC_URI=
#RESTRICT=fetch nostrip
#...snip...
#src_install() {
#   wget ${HOMEPAGE} -O ${WORKDIR}/${MY_P} || die could not fetch 
#distfile
#   cd ${WORKDIR} || die cd ${WORKDIR}
#   tar xfz ${MY_P} || die Failed to extract ${MY_P}
#   mv ${WORKDIR}/etc ${D}/ || die mv etc
#   mv ${WORKDIR}/var ${D}/ || die mv /var
#} 

What I would like to do is create a custom elcass that allows me to replace 
the standard ebuild package fetching routines. It would need to:

1) Check that the source tarball does not already exist.
2) If the correct source tarball does not already exist, fetch it using 
something like wget -O source.tar.gz
3) Rename source.tar.gz to ${DISTDIR}/${PN}-${PV}.tar.gz

My problem is that I cannot seem to locate where any package fetching 
routines are in any of the existing eclasses to use as a template. Another 
thing I am curious about, will custom eclasses in PORTDIR_OVERLAY work 
correctly (assuming they are written correctly).

If anyone could point me in the right direction I would certainly appreciate 
it.


pgpo10lzfuMPi.pgp
Description: PGP signature

Re: [gentoo-portage-dev] Custom eclass question

[Mikey]

On Sunday 09 October 2005 19:36, John Myers wrote:

 Is the id-name mapping 1:1? Since this is an in-house app, can you write
 a script which has nice names, perhaps using $_SERVER['PATH_INFO'], i.e.
 http://codeserver.wherever.net/pman/package_dl.php/mypackage.tar.gz ? In

Actually this is my fallback, figure out how to do it with PATH_INFO.  I 
have been trying to learn more about portage and figured doing a custom 
eclass would be sexier :)


pgprBUPOuJjiG.pgp
Description: PGP signature

Re: [gentoo-portage-dev] Custom eclass question

[Mikey]

On Sunday 09 October 2005 19:32, Marius Mauch wrote:
 Well, ebuilds (and therefore eclasses) can't override anything related
 to the fetch process (other than setting RESTRICT and/or SRC_URI). Your
 problem has to be fixed server side (assuming you want a proper
 solution), as portage *needs* the correct filename in SRC_URI for things
 like md5 verification. So even if $FETCHCOMMAND would save your file
 with the right name you would be in trouble.

I was wondering why pkg_fetch seemed to be the only function that cannot be 
localized in an ebuild...  Why is that?


pgpJ26s9ioDpQ.pgp
Description: PGP signature