Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds

2009-05-21 Thread Arfrever Frehtes Taifersar Arahesis
2009-05-20 20:00:43 Ciaran McCreesh napisał(a):
 On Wed, 20 May 2009 19:12:56 +0200
 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote:
  This error occurs only when there is no up-to-date cache for given
  ebuild. rsync users would see only the usual masked by: EAPI 3
  message.
 
 We always have to assume that there might not be an up to date cache.
 The Gentoo rsync mirrors do not always ship up to date cache,
 particularly if someone's just changed a widely used eclass.

Users can wait an hour and run `emerge --sync` again.
Anyway, Portage still allows to install other ebuilds (with lower EAPI)
of given package, so this corner case doesn't need to slow down progress.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [RFC] Allow bash-4.0 features in EAPI=3 ebuilds

2009-05-21 Thread Ciaran McCreesh
On Thu, 21 May 2009 19:57:49 +0200
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote:
  We always have to assume that there might not be an up to date
  cache. The Gentoo rsync mirrors do not always ship up to date cache,
  particularly if someone's just changed a widely used eclass.
 
 Users can wait an hour and run `emerge --sync` again.

...but that's not what happens. Instead, the users get their screen
spammed with annoying messages, get confused and run to bugzilla in
droves.

This just takes us right back to the bad old days when changing
anything would result in mass user confusion. The whole 'EAPI' thing
wasn't an arbitrary whim.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-21 Thread Robert R. Russell
On Saturday 16 May 2009 20:17:14 Nick Fortino wrote:
 Ciaran McCreesh wrote:
  On Sat, 16 May 2009 16:39:40 -0700
 
  Nick Fortino nfort...@gmail.com wrote:
  Given the above, it should be clear that any argument which states
  some future improvement to the ebuild format  will be impossible based
  upon making the wrong choice between proposal 1 and proposal 2 must be
  invalid, as they have the same expressive power. Note that allowable
  algorithms for which the proof works includes caching and version
  ordering as well as the simple execution of the ebuild.
 
  Unfortunately, your argument is entirely wrong, as can be illustrated
  by a simple counter-example that you would already know about, had you
  read the GLEP or the thread.
 
  With EAPI in a fixed format, it is impossible to allow extensions to the
  version format in future EAPIs. Even given a fixed format and a constant
  extension, adding foo-1.23-rc1.ebuild will cause breakage, but adding
  foo-1.23-rc1.ebuild-4 will not.
 
  This has already been covered at length, and is explained in the GLEP.
  Why did you disregard this when posting your 'proof'?

 I didn't intentionally disregard that case, but I see your point. I made
 the assumption that package mangers wouldn't try to source ebuilds with
 a sourcing EAPI they didn't understand. I concede this is a terrible
 assumption, unless such a thing is specified in the PMS itself. It is
 still fixed by a single extension change, as opposed to a whole set.
 Once this is done, simply state that all package managers should ignore
 EAPIs they don't understand (a requirement of GLEP-55 as well).

 Your point still does not dispute that specifying the EAPI within the
 ebuild and outside the ebuild convey identical information (this is all
 I was trying to prove in the first place). For the case you bring up:
 If foo-1.23-rc1.ebuild is added, it must not be in any of the currently
 existing EAPIs, for if it were, it would be illegal. Thus, a package
 manager would open this file, get the sourcing EAPI in an EAPI
 independent way, realize it doesn't understand, and abort the sourcing
 of that ebuild. Changing the extension once insures current package
 managers don't try to do things they aren't capable of (I apologize for
 not putting this in my first mailing). Given this change, however, I
 still assert the statement of the two schemes have identical expressive
 power.

 For versioning, it has been pointed out (by you and others) that getting
 the latest version would require, under any implementation, opening N
 files in case 1, and reading N file names in case 2. I do not dispute
 this in any way. Instead, I would like to point out that moving the
 argument from features which are possible to support (which I still
 contend are essentially identical), to efficiency vs. a perceived
 prettiness would be significant progress. Indeed, at this point it would
 be possible to make a decision based on reference implementations for
 known common use cases, and an executive council decision about whether
 timing or extension consistency is more important. If it turns out that
 using a solution of type 1 takes minutes to resolve versions, than by
 all means, GLEP-55 is by far the best proposed solution. If, instead,
 the runtime difference in real use cases is negligible, then the pure
 philosophical arguments for using a single extension holds true (in my
 opinion).

 Nick Fortino

And we could probably switch between types if forced to do so.




[gentoo-dev] Re: [RFC] Allow bash-4.0 features in EAPI=3 ebuilds

2009-05-21 Thread Duncan
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org posted
200905211957.55040.arfre...@gentoo.org, excerpted below, on  Thu, 21 May
2009 19:57:49 +0200:

 2009-05-20 20:00:43 Ciaran McCreesh napisał(a):
 On Wed, 20 May 2009 19:12:56 +0200
 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote:
  This error occurs only when there is no up-to-date cache for given
  ebuild. rsync users would see only the usual masked by: EAPI 3
  message.
 
 We always have to assume that there might not be an up to date cache.
 The Gentoo rsync mirrors do not always ship up to date cache,
 particularly if someone's just changed a widely used eclass.
 
 Users can wait an hour and run `emerge --sync` again. Anyway, Portage
 still allows to install other ebuilds (with lower EAPI) of given
 package, so this corner case doesn't need to slow down progress.

Except that users are STRONGLY encouraged (on threat of ban) from syncing 
more than once a day.  A 24-hour wait can seem like a long time, 
especially when you're doing your weekly update on your one off day a 
week, so it's effectively a 7-day wait, or you were updating your folks 
computer on holiday and it could be a multi-month wait, or when 
something's broken that you're depending on to make that presentation in 
the morning and you know the new version fixes it because the bug said so.

If we're going to be saying wait an hour, then let's get rid of the wait 
24-hours thing.  Otherwise, that's mixed messages to users and as Ciaran 
points out, users get confused by such things.

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman




Re: [gentoo-portage-dev] rsync support for fetching binary packages

2009-05-21 Thread Brian Harring
On Tue, May 19, 2009 at 02:47:45PM +0300, Amit Dor-Shifer wrote:
 Hi.
 Looking at getbinpkg.py, I see that BINPKGs can be retrieved using
 http/s s/ftp. I'm wondering about rsync, as it is mostly supported
 across portage (and also in layman). Is there some design reasoning
 behind this lack of support, or is it that no-one has yet gotten around
 to implement it?
 
 I'm raising the question because I'm implementing a private repository
 and would prefer not to service it via http if I don't have to. Right
 now, the only feature which is blocking me is this lack of support for
 binary packages.

Look in the code to be sure, but I'd expect it just hasn't been 
implemented.  If I were in your shoes, I'd generalize the SYNC proto 
support into something usable for binpkgs also- I did this in pkgcore, 
works fairly well (and could be extended to fetching in general, which 
again works well enough).

Personally, I wouldn't dick around with rsync for individual file 
transfers- http/ftp seems better suited, but I may be missing 
something about your setup that warrants it.

Cheers-
~harring


pgpWLgNBHXAcF.pgp
Description: PGP signature