[gentoo-dev] Re: Live source based ebuild proposals
Luca Barbato posted 4996d819.8080...@gentoo.org, excerpted below, on Sat, 14 Feb 2009 15:41:29 +0100: > Let try to clarify: [picking this one to reply to, out of the two] Thanks. That is much easier to follow. =:^) -- 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-dev] Re: Live source based ebuild proposals
Second step, shortcomings.
Luca Barbato wrote:
main problem:
- have the possibility to track upstream w/out having to take a manual
snapshot of their sources, but having portage automatically fetch them
from their tree.
This issue isn't and shouldn't something that touches directly our
normal users, tracking upstream isn't something a common user would do
for any software, upstream releases should be more than enough for
normal usage.
Keyword here being "normal".
Additional concern from ferdy is the fact you may want to track multiple
branches/repos for a software and those do not have a version target.
Ciaranm pointed out already that for such cases you may rely on useflags
to switch between tip repos/branches. I'm not sure useflag should
trigger slot changes (see discussions about binutils usage of useflags),
but still that is a simple and clean enough solution for a quite small
corner case.
Alternatively one could set a virtual and use different package names.
This solution is uglier but I guess would be ok for an overlay.
current situation:
- we have some eclasses that on unpack phase fetch the sources from the
upstream server, prepare them and then the usual ebuild process follows.
- in order to make an ebuild using those eclasses be valued as the
highest possible, the simplest solution had been give it a version "high
enough", namely -. That makes simple track a single tree per package.
- The same could be done with any version component in order to try to
track multiple instances, so to track what will be the next 1.5 version,
somebody could create an ebuild as 1.4. or 1.5_pre, being
an arbitrary big number.
The main issues so far:
- you have to hand produce "high enough" version values
- you cannot track what did you install since you don't have such
information
- you cannot do reemerge (useful for revdep rebuilds)
- in order to refresh them you need either to rely on script or on sets
hand produced or heuristically defined ("all ebuilds that inherit eclass
svn go in svn set").
- since you fetch on unpack phase you cannot use emerge -f consistently
-scm proposal:
- use a component version that makes whatever before it valued as "the
highest within that component", likely -r or _p do, that includes the
case "the highest version in absolute" in order to arbitrary decide an
"high enough" value, namely -.
- from what you can find in the glep, the change is apparently purely
cosmetic beside the hinted but not expressed possibilities having
portage fully aware those ebuild manage something "live" could give.
The issues so far:
- it makes the definition of "high enough number" and marks ebuilds as
live but doesn't address the other issues
- the glep is quite implicit and doesn't tell enough
- it requires changes that aren't exactly low impact for almost no
return, at least apparently since the glep doesn't tell enough.
[I hope that explains better why this proposal had been on hold for this
long and why the main requirement to reconsider it had been to add more
informations in the glep]
live-properity proposal:
- have a property to make portage aware that the ebuild is using live
sources.
- it doesn't add components to the ebuild version but just marks the
ebuild. So this proposal aims to improve portage internal management but
doesn't add or detract anything regarding version resolution.
The issue so far:
- it just solves the fact ebuilds aren't marked as "live" but doesn't
address any of the other problems.
- it has little impact on portage but also gives a little in itself
[That makes this proposal interesting since you may build on it
solutions to the other issues with low impact as well]
live-template proposal:
- you still have a new version component, in this case either ".live" or
"_live", but in the template.
- it isn't used directly in resolution but it generates automatically a
normal version that get resolved as usual.
- tries to make sure there is a way to get reproducible results
regarding installed packages by embedding the informations to get again
the same sources. So you can also re-emerge the very same package again
you emerged it once since it has a defined version number.
- tries to give developers willing to track upstream and then provide
snapshots the ability to do that automatically.
The issue so far:
- it tries to scratches all the itches at the same time.
- it could be as invasive as the -scm proposal but tries to address
every issue in order to make worthy doing such radical changes in one go.
- The proposal itself hasn't covered many implementation and usage
details yet.
[What puzzles me is that some people claims you cannot do something with
live templates while you can with -scm]
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
[gentoo-dev] Last rites: media-video/gephex
+# Peter Alfredsen (15 Feb 2009) +# Masking for removal in 30 days. +# Fails to build with gcc-4.3, bug 250712 +media-video/gephex +
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zac Medico wrote:
> Tiziano Müller wrote:
>> I'd recommend to prefix the digest with a "{TYPE}" (like for hashed
>> passwords) to be able to change the digest algorithm as needed
>> (especially in regards to the current SHA successor competition).
>> This allows a future package manager which might use SHA-3 for hashing
>> (once it's released) to still check old digests. Furthermore it would
>> allow for easier transition and only needs a definition of allowed
>> hashes instead of a specific one.
>
> I like that idea. That way it's not necessary to bump the EAPI in
> order to change the hash function. So, a typical DIGESTS value might
> look like this:
>
> SHA1 02021be38b a28b191904 3992945426 6ec21b29a3
While thinking about the implementation details, I realized that it
would be very useful to give the DIGESTS data a version identifier
that is independent of the EAPI. This will allow a package manager
to validate a cache entry that has been generated for an unsupported
EAPI, and allows it to trust that there's no point in regenerating
the cache entry (to see if the EAPI has changed since the last time
that it was generated). For example, suppose that we introduce EAPI
3 and a package manager that does not support EAPI 3 encounters a
cache entry for an EAPI 3 ebuild. If the package manager recognizes
the DIGESTS data version and it's able to validate the cache entry,
then it can avoid the cost of regenerating metadata for that ebuild.
If the user modifies the ebuild locally to change the EAPI to a
supported EAPI (from 3 to 2, for example), the DIGESTS data will
allow the package manager to recognize that the cache entry has been
invalidated and needs to be regenerated (and it will discover that
the EAPI has changed to a supported value).
So, if a "0" version identifier at the beginning of the DIGESTS
data, a typical entry could look like this:
0 SHA1 02021be38b a28b191904 3992945426 6ec21b29a3
Regardless of what the EAPI value happens to be, the package manager
should be able to trust that the version identifier is a reliable
indicator of the mechanism which should be used to validate the
integrity of the cache entry.
- --
Thanks,
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkmYnFwACgkQ/ejvha5XGaNTzQCdFyZpEBZhftEISVrBBT+DsOHv
JXEAn2KtO/g0KjQtQu8fuB8KGF9Krr/d
=TxtX
-END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
On Sun, 15 Feb 2009 14:51:10 -0800 Zac Medico wrote: > Regardless of what the EAPI value happens to be, the package manager > should be able to trust that the version identifier is a reliable > indicator of the mechanism which should be used to validate the > integrity of the cache entry. Validate it against what? If EAPI is unsupported, the package manager can't make use of INHERITED to see what DIGESTS means. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: > On Sun, 15 Feb 2009 14:51:10 -0800 > Zac Medico wrote: >> Regardless of what the EAPI value happens to be, the package manager >> should be able to trust that the version identifier is a reliable >> indicator of the mechanism which should be used to validate the >> integrity of the cache entry. > > Validate it against what? If EAPI is unsupported, the package > manager can't make use of INHERITED to see what DIGESTS means. In the example given, the DIGESTS version identifier would serve to indicate that the INHERITED field behaves as required by the validation mechanism (regardless of EAPI). If INHERITED can no longer be used like that in a new EAPI, the DIGESTS format/version will have to be bumped. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmYpLMACgkQ/ejvha5XGaN/XwCeNcczP2k4J4LKMDxbmVnWV8v/ cz8AniLUx7fSpEo717IB3nezFZIdcwkr =79XI -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
On Sun, 15 Feb 2009 15:26:44 -0800 Zac Medico wrote: > >> Regardless of what the EAPI value happens to be, the package > >> manager should be able to trust that the version identifier is a > >> reliable indicator of the mechanism which should be used to > >> validate the integrity of the cache entry. > > > > Validate it against what? If EAPI is unsupported, the package > > manager can't make use of INHERITED to see what DIGESTS means. > > In the example given, the DIGESTS version identifier would serve to > indicate that the INHERITED field behaves as required by the > validation mechanism (regardless of EAPI). If INHERITED can no > longer be used like that in a new EAPI, the DIGESTS format/version > will have to be bumped. So in effect we're introducing a second level of versioned compatibility testing? Strikes me as excessive, especially since it only works for EAPIs where the scope of changes is small enough to keep the meaning of INHERITED and DIGESTS the same... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: > On Sun, 15 Feb 2009 15:26:44 -0800 > Zac Medico wrote: Regardless of what the EAPI value happens to be, the package manager should be able to trust that the version identifier is a reliable indicator of the mechanism which should be used to validate the integrity of the cache entry. >>> Validate it against what? If EAPI is unsupported, the package >>> manager can't make use of INHERITED to see what DIGESTS means. >> In the example given, the DIGESTS version identifier would serve to >> indicate that the INHERITED field behaves as required by the >> validation mechanism (regardless of EAPI). If INHERITED can no >> longer be used like that in a new EAPI, the DIGESTS format/version >> will have to be bumped. > > So in effect we're introducing a second level of versioned > compatibility testing? Strikes me as excessive, especially since it > only works for EAPIs where the scope of changes is small enough to > keep the meaning of INHERITED and DIGESTS the same... If the package manager is not able to validate a cache entry that has been generated for an unsupported EAPI, then it will be forced to regenerate the metadata in order to check whether or not the EAPI has changed (example given 2 emails ago). Don't you agree that it would be useful to be able to avoid metadata generation in cases like this, if possible? - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmYq6EACgkQ/ejvha5XGaNumwCeIqaACk67tlvtQNBppUsuOknN 8agAoN8ZuPYQ5KiFMJj/5syG2/mNqgaE =zffn -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
On Sun, 15 Feb 2009 15:56:18 -0800 Zac Medico wrote: > If the package manager is not able to validate a cache entry that > has been generated for an unsupported EAPI, then it will be forced > to regenerate the metadata in order to check whether or not the EAPI > has changed (example given 2 emails ago). Don't you agree that it > would be useful to be able to avoid metadata generation in cases > like this, if possible? Well... The solution you give only *sometimes* avoids it, so it's only worth it if we expect that most EAPI changes won't mess around with inheriting at all. And given that we probably want per-cat/pkg eclasses... It only comes into its own if you expect there to be a long time between an EAPI being used in the tree and an EAPI being supported by a package manager. And even then, it's probably easier to just do a minor stable release straight away with rules for "don't know how to use this EAPI, but do know how to read metadata cache entries for it" whilst keeping new EAPI support for the next major release. Honestly, I don't think it'll be useful often enough that it's worth the added ick. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2009-02-15 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2009-02-15 23h59 UTC. Removals: xfce-extra/verve2009-02-09 19:55:39 angelos sys-kernel/rsbac-sources2009-02-11 23:24:31 gengor sys-apps/rsbac-admin2009-02-11 23:26:10 gengor mail-client/xfmail 2009-02-15 20:27:33 tove mail-client/elm 2009-02-15 21:14:43 tove app-editors/katoob 2009-02-15 23:13:02 loki_val Additions: net-misc/mico 2009-02-09 16:49:04 haubi xfce-extra/xfce4-verve 2009-02-09 19:52:46 angelos dev-python/cssutils 2009-02-10 13:15:01 lordvan x11-plugins/pidgin-musictracker 2009-02-10 17:59:18 serkan app-dicts/ispell-de-alt 2009-02-11 14:50:45 ulm dev-java/wstx 2009-02-11 15:27:56 betelgeuse app-emacs/scala-mode2009-02-11 15:58:03 ulm dev-util/qt-creator 2009-02-11 23:35:33 hwoarang kde-misc/kcometen4 2009-02-12 19:43:29 hwoarang x11-plugins/pidgin-sipe 2009-02-13 15:56:43 drizzt net-mail/vchkuser 2009-02-14 19:55:55 hollow games-puzzle/world-of-goo-demo 2009-02-15 00:00:37 vapier games-puzzle/world-of-goo 2009-02-15 00:15:32 vapier dev-perl/Math-Calc-Units2009-02-15 18:21:43 tove dev-perl/Nagios-Plugin 2009-02-15 20:33:22 dertobi123 media-video/elltube 2009-02-15 23:20:17 hwoarang -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: xfce-extra/verve,removed,angelos,2009-02-09 19:55:39 sys-kernel/rsbac-sources,removed,gengor,2009-02-11 23:24:31 sys-apps/rsbac-admin,removed,gengor,2009-02-11 23:26:10 mail-client/xfmail,removed,tove,2009-02-15 20:27:33 mail-client/elm,removed,tove,2009-02-15 21:14:43 app-editors/katoob,removed,loki_val,2009-02-15 23:13:02 Added Packages: net-misc/mico,added,haubi,2009-02-09 16:49:04 xfce-extra/xfce4-verve,added,angelos,2009-02-09 19:52:46 dev-python/cssutils,added,lordvan,2009-02-10 13:15:01 x11-plugins/pidgin-musictracker,added,serkan,2009-02-10 17:59:18 app-dicts/ispell-de-alt,added,ulm,2009-02-11 14:50:45 dev-java/wstx,added,betelgeuse,2009-02-11 15:27:56 app-emacs/scala-mode,added,ulm,2009-02-11 15:58:03 dev-util/qt-creator,added,hwoarang,2009-02-11 23:35:33 kde-misc/kcometen4,added,hwoarang,2009-02-12 19:43:29 x11-plugins/pidgin-sipe,added,drizzt,2009-02-13 15:56:43 net-mail/vchkuser,added,hollow,2009-02-14 19:55:55 games-puzzle/world-of-goo-demo,added,vapier,2009-02-15 00:00:37 games-puzzle/world-of-goo,added,vapier,2009-02-15 00:15:32 dev-perl/Math-Calc-Units,added,tove,2009-02-15 18:21:43 dev-perl/Nagios-Plugin,added,dertobi123,2009-02-15 20:33:22 media-video/elltube,added,hwoarang,2009-02-15 23:20:17 Done.
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: > On Sun, 15 Feb 2009 15:56:18 -0800 > Zac Medico wrote: >> If the package manager is not able to validate a cache entry that >> has been generated for an unsupported EAPI, then it will be forced >> to regenerate the metadata in order to check whether or not the EAPI >> has changed (example given 2 emails ago). Don't you agree that it >> would be useful to be able to avoid metadata generation in cases >> like this, if possible? > > Well... The solution you give only *sometimes* avoids it, so it's only > worth it if we expect that most EAPI changes won't mess around with > inheriting at all. And given that we probably want per-cat/pkg > eclasses... Well, I think it's more like "the vast majority of the time" than just "sometimes", and it's a lot better than "never". > It only comes into its own if you expect there to be a long time > between an EAPI being used in the tree and an EAPI being supported by a > package manager. And even then, it's probably easier to just do a minor > stable release straight away with rules for "don't know how to use this > EAPI, but do know how to read metadata cache entries for it" whilst > keeping new EAPI support for the next major release. But how will it know if it supports those cache entries? Wouldn't the easiest way to determine that be to have a DIGESTS version identifier? Otherwise, the only way for it to know would be to parse it and either throw a parse error if necessary or proceed all the way to the digest verification step (if it doesn't hit a parse error first). > Honestly, I don't think it'll be useful often enough that it's worth > the added ick. Doesn't a simple version identifier seem less icky than checking for both a parse error and digest verification failure? - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmYt+oACgkQ/ejvha5XGaOC6gCgzgIcH6D7X/o/vOuWvsS0mp42 dGsAn17xnY8bX9IG28Uj3MX42qdrxGrL =+Hkp -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico wrote: > Ciaran McCreesh wrote: >> On Sun, 15 Feb 2009 15:56:18 -0800 >> It only comes into its own if you expect there to be a long time >> between an EAPI being used in the tree and an EAPI being supported by a >> package manager. And even then, it's probably easier to just do a minor >> stable release straight away with rules for "don't know how to use this >> EAPI, but do know how to read metadata cache entries for it" whilst >> keeping new EAPI support for the next major release. > > But how will it know if it supports those cache entries? Wouldn't > the easiest way to determine that be to have a DIGESTS version > identifier? Otherwise, the only way for it to know would be to parse > it and either throw a parse error if necessary or proceed all the > way to the digest verification step (if it doesn't hit a parse error > first). Well, I guess you were saying that it should just use the EAPI. Given that we don't have much control over how often users upgrade, I'd still prefer to have a DIGESTS version identifier. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmYuUsACgkQ/ejvha5XGaOIcQCfctQ/heCKDzGmls3NNLulodsD g2AAnAwOd/JD+sHvDBPQSmx2LOHOiqjw =onL8 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] DIGESTS metadata variable for cache validation
On Sun, 15 Feb 2009 16:48:44 -0800 Zac Medico wrote: > > It only comes into its own if you expect there to be a long time > > between an EAPI being used in the tree and an EAPI being supported > > by a package manager. And even then, it's probably easier to just > > do a minor stable release straight away with rules for "don't know > > how to use this EAPI, but do know how to read metadata cache > > entries for it" whilst keeping new EAPI support for the next major > > release. > > But how will it know if it supports those cache entries? Wouldn't > the easiest way to determine that be to have a DIGESTS version > identifier? Otherwise, the only way for it to know would be to parse > it and either throw a parse error if necessary or proceed all the > way to the digest verification step (if it doesn't hit a parse error > first). You just need to give your package manager a way of dealing with EAPIs where it can verify that DIGESTS is correct, but not make use of the ebuild in question beyond that. Rather than having supported and unsupported EAPIs, have supported, partially-understood and unsupported EAPIs. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Last rites: media-video/gephex
Peter Alfredsen posted 20090215212907.00a73...@gentoo.org, excerpted below, on Sun, 15 Feb 2009 21:29:07 +0100: > +# Peter Alfredsen (15 Feb 2009) > +# Masking for removal in 30 days. > +# Fails to build with gcc-4.3, bug 250712 > +media-video/gephex > + Shouldn't there be a bit more to it than that, something about it being maintainer-needed, or maintainer unwilling to work on it further, or upstream dead, or some combination of the above? Just because it doesn't compile with the latest GCC isn't normally considered reason in itself to remove a package. Also note that there's a "new" (April, 2007) version 0.4.4, on the site, that may work better with newer gcc than the 2005 version 0.4.3 that's the latest in our tree. So maybe it well could be maintainer-needed, but that should be in the masking for removal reason, if so, and ideally, listed in the last rites announcement here, in case anyone's interested in taking a look at it. That said, I don't have any particular interest in it, so I don't have a problem with it disappearing. I just found the ONLY reason given an uncommon enough reason for removal on its own that it warranted comment, is all. -- 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-dev] Re: Last rites: media-video/gephex
Le 16/02/2009 07:17, Duncan a écrit : That said, I don't have any particular interest in it, so I don't have a problem with it disappearing. I just found the ONLY reason given an uncommon enough reason for removal on its own that it warranted comment, is all. Hence the 30-day period when removing packages. Interested users/devs have enough time to come forward and pick it up if they want to. Cheers, Rémi
[gentoo-dev] Re: Last rites: media-video/gephex
On Mon, 16 Feb 2009 06:17:04 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > Peter Alfredsen posted > 20090215212907.00a73...@gentoo.org, excerpted below, on Sun, 15 Feb > 2009 21:29:07 +0100: > > > +# Peter Alfredsen (15 Feb 2009) > > +# Masking for removal in 30 days. > > +# Fails to build with gcc-4.3, bug 250712 > > +media-video/gephex > > + > > Shouldn't there be a bit more to it than that, something about it > being maintainer-needed, or maintainer unwilling to work on it > further, or upstream dead, or some combination of the above? Just > because it doesn't compile with the latest GCC isn't normally > considered reason in itself to remove a package. > > Also note that there's a "new" (April, 2007) version 0.4.4, on the > site, that may work better with newer gcc than the 2005 version 0.4.3 > that's the latest in our tree. So maybe it well could be > maintainer-needed, but that should be in the masking for removal > reason, if so, and ideally, listed in the last rites announcement > here, in case anyone's interested in taking a look at it. > > That said, I don't have any particular interest in it, so I don't > have a problem with it disappearing. I just found the ONLY reason > given an uncommon enough reason for removal on its own that it > warranted comment, is all. read the bug. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
