Re: [gentoo-dev] Re: [RFC] Required Features for $package_manager to Aid... Development!

[Francesco Riosa <vivo@gentoo.org>]

Alec Warner wrote:
> Chris Gianelloni wrote:
>> On Wed, 2006-09-06 at 21:19 -0600, Ryan Hill wrote:
>>> Elfyn McBratney wrote:
>>>
>>>> I've been inspired by the local/global USE flag threads recently
>>>> posted by Doug (Cardoe), and it got me to thinking... I've recently
>>>> joined the pkgcore development effort, and was asked by Brian
>>>> (ferringb) what I'd like to hack on/what my niggles with portage are.
>>>> My personal one is why updates/ and binpkg mangling takes so long in
>>>> portage-$current.  But I'd like to know, what are everyone elses?
>>> I've been thinking about this lately too.  I think it would be a good 
>>> idea to come up with as many different use cases as we can think of and 
>>> figure out what we can already do, what we would like to do, and the 
>>> best way to do it.
>>>
>>>> I know that this topic have been rehashed since the dawn of
>>>> time^Wgentoo-dev, but these things get lost, opinions change... and
>>>> since last year, new and viable alternate package managers have
>>>> cropped up.  So, basically I'd like to ask all on this list: - what
>>>> package manager features would make *your* life easier?
>>> - current pet peeve is some way of dealing with SRC_URI's that use 
>>> dynamic redirects to the source files (eg. 
>>> http://nwvault.ign.com/fms/Download.php?id=57167 -> 
>>> http://someserver.com/randomlygeneratedhashthatchangeseveryhour/the_HeX_coda_01_v1.3.zip). 
>>>   Since the name of the file fetched (the_HeX_coda_01_v1.3.zip) != the 
>>> one in SRC_URI (Download.php?id=57167) portage bombs.  right now i have 
>>> to use RESTRICT="fetch" which sucks.
>> There's also any SRC_URI that includes an "&"...
>>
>> There are some things that I would like to see from a Release
>> Engineering standpoint.  These are things that I would like some way to
>> obtain, not necessarily from the normal user "front-end" to
>> $package_manager, but somehow.
>>
>> #1. Ability to grab USE from the environment for a machine both before
>> and after USE_EXPAND is calculated
>> #2. Ability to ignore environment's USE when doing calculations, such as
>> the easily grabbing the contents of the "system" target with the default
>> USE for a profile
> 
> This is possible via USE_ORDER, you can turn whatever stacking you like
> on or off.  It's usage is not supported (as in you break it you fix it);
> mostly this is to prevent users from futzing with USE_ORDER and then
> complaining to us about it.
> 
>> #3. Ability to list the stable package versions for a given profile
>> #4. Ability to list the testing package versions for a given profile
>> #5. Ability to list the used USE flags in a given set of packages
>> #6. Ability to list the licenses used in a given set of packages (this
>> is especially important as we are seeing more and more packages that we
>> are not allowed to redistribute being used accidentally)
>> #7. Ability to list the packages that use a given set of licenses
>> #8. Ability to list the dependency tree for packages, even if some of
>> the dependencies are masked by keywords, rather than throwing up the
>> "this package is masked by keywords" error for each one, allowing one to
>> see *quickly* all of the packages that need keyword changes for a
>> particular package to have its keywords changed... fex. "emerge
>> --keywords =kde-base/kde-4.0" should list all of KDE 4.0's dependencies,
>> and anything that is masked by keywords should show up as "~" or
>> something... anything masked by package.mask should show up as "M"...
>> this should have a way of choosing to ignore profile-level masks or not,
>> also... this is just an example, how we actually get the information
>> doesn't matter, so long as we can get it...
> 
> This is a tricky one (and often asked for!).  The output would be a
> guess at best though.
> 
> A : Depends on B
> B-1 : Depends on C
> B-2 : Depends on C,D,E
> 
> All versions of B are masked; so either you get
> 
> A
> ~B (Warning B is masked)
> 
> or you get
> 
> A
> ~B (Warning B is masked)
> C
> 
> or
> 
> A
> ~B (Warning B is masked)
> C
> D
> E
> 
> This depends of course on which version of B we choose.  This is why
> this request isn't implemented; there is no good heuristic for making
> this choice and in complex dependency trees, bad choices lead to bad
> results.

What about to decide for the less dangerous, less keywording route ?
follow pseudo-pseudo-code:

def find_all_dependants_recursive(\
  pkg, \
  acceptable_version_range='0..inf', \
  already_needed={}, \
  recursion_level=0 \
  )

  SELECT p.version, p.stability, p.depends
  INTO %p_version, %p_stable_level, %p_depends
  FROM packages AS p
  WHERE p.version BETWEEN %acceptable_version_range
  ORDER BY p.version DESC, p.stability
  LIMIT 1

  if already_needed.has_key(pkg):
    """
    already encountered this package,
    check that current needs are ok
    """

    if \ %p_version.inside(already_needed[pkg]['acceptable_version_range']):
      """
      TOCHECK:
      the range is compatible, do nothing ?
      """
      pass
    else:
      # damn, we need to try harder to look if there is a good
      # package version
      if \
already_needed[pkg]['acceptable_version_range'].inside(acceptable_version_range):
        # we can try the luck
        already_needed[pkg] = find_a_good_one(\
          pkg, \
          already_needed[pkg]['acceptable_version_range']
        )
      else:
        # there is no possibility to find a good package,
        # the tree is broken
        throw_error,_clean_and_die()
  else:
    already_needed[pkg] = {\
    'acceptable_version_range' : acceptable_version_range, \
    'version' : %p_version, \
    'stable_level' : %p_stable_level \
    }

  for dpkg in %p_depends:

    find_all_dependants_recursive(\
    %p_depends['pkg'], \
    %p_depends['acceptable_version_range'], \
    already_needed, \
    recursion_level +1 \
    )

  if recursion_level == 0:
    einfo('yay')
    return already_needed

  return 42


def find_a_good_one(pkg, acceptable_version_range)
  SELECT p.version, p.stability, p.depends
  INTO %p_version, %p_stable_level
  FROM packages AS p
  WHERE p.version BETWEEN %acceptable_version_range
  ORDER BY p.version DESC, p.stability
  LIMIT 1

  return {\
    'acceptable_version_range' : acceptable_version_range, \
    'version' : %p_version, \
    'stable_level' : %p_stable_level \
    }


if __name__ == "__main__":
  print find_all_dependants_recursive('dev-db/i_am_a_bad_puppy')

-- 
gentoo-dev@gentoo.org mailing list