[gentoo-dev] DRAFT GLEP: MULTI-REPO
Attached is a draft of a glep for formalizing multiple-repository support This is far from ideal in many ways, but i'm too tired and I drank too much caffine to be sane. Also, i have no clue how to use docutils so i just tried my best. (** is my way of doing another level of bullets, please let me know how to properly do this) Comments, objections, anything consructive is welcome. Thanks, Andrew Muraco GLEP: XX Title: Multiple Repository Support in Portage Version: $Revision: 1.0 $ Author: Andrew Muraco [EMAIL PROTECTED] Last-Modified: $Date: 2005/12/17 03:13:10 $ Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 17-Dec-2005 Post-History: 17-Dec-2005 Abstract To implement a functional and expandable method for Portage to support multiple repositories. Motivation == Multiple Repository support is needed, this GLEP is to address this need. Specification = Portage will make use of two (2) ways to address repositories: * A User-defined name, which is likely to be used as a convinance in most situations - this will be referred to as REPO_NAME in this GLEP * A hard-coded repository-id which will be found in the repository tree at: metadata/repo_id - this will be referred to as REPO_ID in this GLEP Both names will contain no spaces, and only standard characters [TODO: references] Repositories Each repository will contain: * the repo name in metadata/repo_id * repo information such as maintainer of the repo, notes on who hosts it, etc will be contained metadata/repo_info * unique packages.mask which will only apply to ebuilds within that specific repo. The REPO_ID must match the name that will be used for rsync Therefore, rsync://MyServer.tdl/REPO_ID/ /etc/portage/* - In order to provide users with the current set of options and extend them so they can be customized to each repository, the structure of /etc/portage will remain similar with these changes: * /etc/portage/REPO_NAME/* will be the location of repository-specific portage files. * /etc/portage/ will continue to function over all repos ** ex) =sys-devel/gcc-4 -* in /etc/portage/package.keywords would use the latest gcc-4 regardless of what tree it comes from. The following new files will be added to /etc/portage: * /etc/portage/repositories.perfer - will contain each REPO_NAME in order of preferance, higher is more perfered. (Each REPO_NAME will be on a seperate line) ** In the absence of this file portage should use repositories in alphabetical order. * /etc/portage/REPO_NAME/repository.id - contains the specific REPO_ID which REPO_NAME applies to. */etc/portage/REPO_NAME/repository.conf - will contain any repository-specific options, which can include, but is not limited to, FEATURES= C[XX]FLAGS=. ** This will also include a new variable; OPTIONS= of which is similar to FEATURES, but modifies the way portage will handle that specific repository. A few examples of options which could be useful: *** EXCLUDESYNC - Prevents portage from doing a sync on this repo. *** EXCLUDEUPDATE - Prevents portage from using ebuilds in this repo as updates for packages which currently reside in a different repo. *** EXCLUSIVEUPDATE - forces any update to any package which is from this repository to a newer version which resides inside of this repo. *** et al. All of the repository rsync URIs will be stored in /etc/make.conf SYNC=rsync://myfavoriterepo.org/myportage \ rsync://rsync.namerica.gentoo.org/gentoo-portage The Tree: /usr/portage - /var/repositories/REPO_ID/ -- The repository tree will need to be moved, each repository will have its own folder: /var/repositories/REPO_ID/. For compatibility reasons, /usr/portage will be treated as /var/repositories/gentoo-portage Ebuilds --- Ebuilds will now be able to have dependencies based on packages from specific repositories. * DEP Atoms now support the following format: =REPO_ID:SLOTNUM:CAT/EBUILD-X.Y.Z ** Ex1) =MyRepo:2:sys-devel/gcc-4.0 ** Ex2) gentoo-portage::kde-base/kdelibs-3.5 ** Ex3 ::foo/bar Dependency atoms that lack the new format (::) or do not have a REPO_ID will then just use any ebuild which fulfills the requirements. /var/db/pkg/ Along with other information about the building of packages, the specific repo which provided the ebuild will be recorded. /var/db/pkg/cat/package/REPOSITORY will contain REPO_ID If no REPOSITORY file is found, then gentoo-portage is assumed. Backwards Compatibility === /usr/portage will be treated as /var/repositories/gentoo-portage so it would be possible to function with no changes after the upgrade. Packages in /var/db that lack REPOSITORY will be assumed to be gentoo-portage. References == [TODO] Copyright = This document has been placed in the public domain.
Re: [gentoo-dev] DRAFT GLEP: MULTI-REPO
I apologize for the caps in the subject. Andrew Muraco -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [GLEP] Manifest2 format
As promised here the GLEP for Manifest2 support: http://www.gentoo.org/proj/en/glep/glep-0044.html I like it - well done Marius. -- Daniel Black [EMAIL PROTECTED] Gentoo Crypto/PPC/dev-embedded/Forensics/NetMon pgpD3JojbdJir.pgp Description: PGP signature
[gentoo-dev] last rites for net-im/sim
When you are interested in sim and willing to fix all bugs¹ and takeover maintainership) speak now. Christmas morning I'll crucify it. Carsten [1] https://bugs.gentoo.org/show_bug.cgi?id=110241 pgplrITLoIEF7.pgp Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
Zac Medico wrote: Ciaran McCreesh wrote: except that it moves it deeper down into the how do I determine whether this news item is relevant? area. And the only way to get around that would be to move even more code into Portage than you're already proposing. Are the currently specified Display-If-* headers insufficient for some reason? Looking into this a little further, it seems that Display-If-Installed can be implemented with `portageq match / atom` and Display-If-Keyword can be implemented with `portageq envvar ARCH`. That leaves Display-If-Profile which may require a new portageq query in order to cleanly retrieve the profile. Perhaps something like profile=$(portageq profile) would be sufficient? Zac -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Sat, 17 Dec 2005 12:38:24 -0800 Zac Medico [EMAIL PROTECTED] wrote: | Looking into this a little further, it seems that | Display-If-Installed can be implemented with `portageq match / | atom` and Display-If-Keyword can be implemented with `portageq | envvar ARCH`. That leaves Display-If-Profile which may require a new | portageq query in order to cleanly retrieve the profile. Perhaps | something like profile=$(portageq profile) would be sufficient? Well, that depends... If you have sys-apps/foo installed from the gentoo-x86 repository, and the breakmygentoo repository issues a news item about sys-apps/foo, should it be displayed? -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
Ciaran McCreesh wrote: Well, that depends... If you have sys-apps/foo installed from the gentoo-x86 repository, and the breakmygentoo repository issues a news item about sys-apps/foo, should it be displayed? Well, probably not. Off hand, perhaps portageq could provide a query that returns some type of UUID for a package, such as a hash of the ebuild. That way, the hash from /var/db/pkg could be compared to the hash from the repo that has the news item. If the hashes don't match, then the news item is irrelevant. Zac -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
On Sat, 17 Dec 2005 13:16:04 -0800 Zac Medico [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | Well, that depends... If you have sys-apps/foo installed from the | gentoo-x86 repository, and the breakmygentoo repository issues a | news item about sys-apps/foo, should it be displayed? | | Well, probably not. Off hand, perhaps portageq could provide a query | that returns some type of UUID for a package, such as a hash of the | ebuild. That way, the hash from /var/db/pkg could be compared to the | hash from the repo that has the news item. If the hashes don't | match, then the news item is irrelevant. Now do you see why I don't want to touch multi repo support without a proper specification describing how it'll work? :) -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Multiple Repo Support
On Sat, Dec 17, 2005 at 09:21:45PM +, Ciaran McCreesh wrote: On Sat, 17 Dec 2005 13:16:04 -0800 Zac Medico [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | Well, that depends... If you have sys-apps/foo installed from the | gentoo-x86 repository, and the breakmygentoo repository issues a | news item about sys-apps/foo, should it be displayed? | | Well, probably not. Off hand, perhaps portageq could provide a query | that returns some type of UUID for a package, such as a hash of the | ebuild. That way, the hash from /var/db/pkg could be compared to the | hash from the repo that has the news item. If the hashes don't | match, then the news item is irrelevant. Now do you see why I don't want to touch multi repo support without a proper specification describing how it'll work? :) Multi repo support is actually pretty simple, and doesn't require yet another glep/spec/paperwork- it's been sitting in the saviour branch for as long as the domain class has existed (3+ months); stand alone repository support (matching within that repo) is a resolver thing, where we're at in saviour is normal PORTDIR capabilities for all specified repo's (standalone, overlay, or otherwise). It's not that bloody hard to get it working- all of the noise here is about further additions to it (which is fine, but kindly rememeber that fact), noise which I'd *rather* see resolved down the line. Why? Frankly, the majority of this is portage internal crap. Either extension of portageq api, or extension of atom syntax. Unique ID's per packages isn't a good idea offhand. What's needed for the comments above is the ability to search installed pkg db's for pkgs yielded from repo ID x. Enter the restriction subsystem. Add a repo level matching class, and you've got the search right there. Pretty simple, actually, and not requiring yet another glep for saviour. Back in the land of stable, here's how it should be done- portageq root atom [repo id] ex: portageq / sys-apps/foo break my gentoo simple mod. Lack of repo id is old rules, match anything and everything. This actually can be implemented *now* without requiring a bunch of handwaving about specs/gleps. Next issue? ~harring pgp1aAP8lv5g0.pgp Description: PGP signature
Re: [gentoo-dev] draft glep: multi-repo
Pardon bluntness; don't mean offense, just specifically picking the hell out of this proposal to make a point (lucky you) :) On Sat, Dec 17, 2005 at 03:17:44AM -0500, Andrew Muraco wrote: Attached is a draft of a glep for formalizing multiple-repository support I appreciate trying to chip in, but frankly this glep needs a lot more thought put into it. Further, I _really_ do not see the point of glepping this either. Puking up proposals due to folks making noise is a waste of time- don't document/propose just because folks are making noise- do it for large scale changes, or conflict, not because someone requires a glep/spec before they're willing to listen to the _developers_ of a project about how to integrate a new feature into _their_ project. This is far from ideal in many ways, but i'm too tired and I drank too much caffine to be sane. Comments, objections, anything consructive is welcome. Inlined... Abstract To implement a functional and expandable method for Portage to support multiple repositories. Motivation == Multiple Repository support is needed, this GLEP is to address this need. define multiple repository. We _have_ multi repo already (binpkg and portdir, let alone overlays). Specification = Portage will make use of two (2) ways to address repositories: * A User-defined name, which is likely to be used as a convinance in most situations - this will be referred to as REPO_NAME in this GLEP * A hard-coded repository-id which will be found in the repository tree at: metadata/repo_id - this will be referred to as REPO_ID in this GLEP Both names will contain no spaces, and only standard characters [TODO: references] Portage externally will use user defined, internally it will do it's own thing. Repositories Each repository will contain: * the repo name in metadata/repo_id * repo information such as maintainer of the repo, notes on who hosts it, etc will be contained metadata/repo_info * unique packages.mask which will only apply to ebuilds within that specific repo. The REPO_ID must match the name that will be used for rsync Therefore, rsync://MyServer.tdl/REPO_ID/ No. It's arbitrary, and invalid to assume rsync is the only sync uri that's going to be used- this isn't even getting into _remote_ repos. *ANY* unique id tagged into a repo is just that, a magic constant in it's metadata. Just that. No mandates about SYNC, file layout, etc, will fly that bind to the metadata id. /etc/portage/* - In order to provide users with the current set of options and extend them so they can be customized to each repository, the structure of /etc/portage will remain similar with these changes: * /etc/portage/REPO_NAME/* will be the location of repository-specific portage files. * /etc/portage/ will continue to function over all repos ** ex) =sys-devel/gcc-4 -* in /etc/portage/package.keywords would use the latest gcc-4 regardless of what tree it comes from. The following new files will be added to /etc/portage: * /etc/portage/repositories.perfer - will contain each REPO_NAME in order of preferance, higher is more perfered. (Each REPO_NAME will be on a seperate line) yuck. This is a bit of a waste for a single file. **In the absence of this file portage should use repositories in alphabetical order. directory returned ordering, not alpha- no ordering == set of repositories, thus don't try to induce a fallback ordering. * /etc/portage/REPO_NAME/repository.id - contains the specific REPO_ID which REPO_NAME applies to. This is going to induce more slowdown for any config instantiation- more directories/files to scan. Iow, python -c 'import portage' (which instantiates a config obj), is going to get slower, which will piss off the slower system folk even further (hell, even with 1.5ghz and decent IO it still is a 10s import for me uncached). */etc/portage/REPO_NAME/repository.conf - will contain any repository-specific options, which can include, but is not limited to, FEATURES= C[XX]FLAGS=. **This will also include a new variable; OPTIONS= of which is similar to FEATURES, but modifies the way portage will handle that specific repository. A few examples of options which could be useful: This seems a bit arbitrary. *** EXCLUDESYNC - Prevents portage from doing a sync on this repo. And how are you going to specify the sync method for that repo? *** EXCLUDEUPDATE - Prevents portage from using ebuilds in this repo as updates for packages which currently reside in a different repo. *** EXCLUSIVEUPDATE - forces any update to any package which is from this repository to a newer version which resides inside of this repo. And this is implemented how? Why is it specifying resolver directives as repo attributes? When is this forced -U going to be triggered? Sync?
[gentoo-dev] problems crosscompiling libXt
Hey all,
Here is a fix for libXt, similar to the problems I had with libX11
last week. I don't see an obvious way to patch the Makefile.am.
Please send comments.
Symptom:
../util/makestrs -i .. ../util/string.list StringDefs.c
/bin/sh: ../util/makestrs: cannot execute binary file
make[2]: *** [StringDefs.c] Error 126
For this to work, have a look at the ebuild in the forwarded msg.
Fix patchfile:
--- util/Makefile.in
+++ util/Makefile.in
@@ -48,7 +48,7 @@
AUTOHEADER = @AUTOHEADER@
AUTOMAKE = @AUTOMAKE@
AWK = @AWK@
-CC = @CC@
+CC = gcc
CCDEPMODE = @CCDEPMODE@
CFLAGS = @CFLAGS@
CPP = @CPP@
On Fri, Dec 09, 2005 at 03:19:28AM -0500, David Thomas ([EMAIL PROTECTED])
wrote:
Subject: [gentoo-embedded] problems crosscompiling libX11
Message ID: [EMAIL PROTECTED]
I've been having problems with libX11. First it tries to build a binary
with the crosscompiler then execute it:
/bin/sh: ../src/util/makekeys: cannot execute binary file
I wrote a patch that fixes this... See below.
I'm still having a problem with libtool. The last step of the build process
it does the following:
/bin/sh ../libtool --mode=link armv5l-softfloat-linux-uclibc-gcc ... -L
/newroot/usr/lib ...
...(much more)... -lXau -lXdmcp -ldl
This calls the crosscompiler replacing -lXau and -lXdmcp with
/usr/lib/libXau.so and
/usr/lib/libXdmcp.so INSTEAD of the crosscompiled ones in /newroot/usr/lib
Same thing even if I hardcode values in ../libtool for
sys_lib_search_path_spec.
I also tried setting an LDPATH in /etc/env.d/05crosscompiler.
Am I missing something in /etc/ld.so.conf environment?
Thanks!
Dave Thomas
Here are the fixes:
Added to ebuild (is this right? comments? it seems to work):
src_unpack()
{
x-modular_unpack_source
x-modular_patch_source
cd ${S}
epatch /path/to/patchfile
x-modular_reconf_source
}
patchfile:
--- src/util/Makefile.am
+++ src/util/Makefile.am
@@ -4,7 +4,8 @@
makekeys_CFLAGS=$(X11_CFLAGS) $(BIGREQS_CFLAGS)
-#override CC = gcc
+#do not override CC, this is needed when using a crosscompiler since this
executable is to be run on $build not $host
+CC = gcc
LINK = $(CC) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@
EXTRA_DIST = mkks.sh
--- src/util/Makefile.in
+++ src/util/Makefile.in
@@ -189,8 +189,9 @@
makekeys_CFLAGS = $(X11_CFLAGS) $(BIGREQS_CFLAGS)
-#override CC = gcc
+#no, do not override CC, this is needed when using a crosscompiler since
this executable is to be run on $build not $host
+CC = gcc
LINK = $(CC) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@
__END__
--
gentoo-embedded@gentoo.org mailing list
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Wed, Dec 14, 2005 at 09:54:06PM +, Ciaran McCreesh wrote: On Wed, 14 Dec 2005 13:48:45 -0800 Zac Medico [EMAIL PROTECTED] wrote: | I wish you'd reconsider, because I was looking forward to multiple | repository support. Well, if Portage ever gets multiple repository support, then news clients can be updated to handle it. The GLEP says that already. Care to clarify how that transition is going to occur? Your proposal, if you know a roadblock is coming down the line I expect it to be documented in the glep (with potential suggestions how to minimize the horkage). If you're not going to do N repo, state so in the glep, state that it _will_ break down the line, and that the issue while known, are being ignored despite portage developers concerns. Only fair the council knows the exact details, that and it made clear that this was known when proposed and ignored. If you're going to create and dump a mess on us, I expect it to be in the proposal- especially since your proposal is intrinsically portage bound. Thing that's daft out of all of this time wasting is that what's being asked of you is a couple of portageq calls so that we're not screwed over by a feature. Something along the lines of... portageq get_repo_id path # helper method of getting repo_id for a path (dar) portageq match root atom [repo-id] # method of limiting matching of vdb to a specific source repo portageq newsdir repo_id # get the absolute news path for said id. Integration for that is pretty damn simple from our side of things, and you get the major blocker of your news glep resolved (meaning it has a chance of actually passing). If it's too slow, I'd suggest since it's your proposal, looking for a method to batch up the calls (modularization of portageq would be required, which is available in the dead ebd branch already). Tricks of that sort are easily implemented, and don't require specs and gleps (just requires someone to do a minor bit of work). ~harring pgpQEwhHt8ZlE.pgp Description: PGP signature
Re: [gentoo-dev] draft glep: multi-repo
On Sat, Dec 17, 2005 at 11:25:58PM +, Ciaran McCreesh wrote: On Sat, 17 Dec 2005 15:15:48 -0800 Brian Harring [EMAIL PROTECTED] wrote: | True stand alone repository capabilities aren't required/bound to | glep42, all that's required out of glep42 is that the syncing repo id | be used now (even if it may seem superfluous). Iow, news *should* | work regardless if it's an overlay or a stand alone repo. Not quite true. I also need to know how to handle Display-If-Installed and Display-If-Profile headers with multiple repositories. Hence why I'd prefer to leave it as something that can easily be implemented in the future... News is repo specific. What I stated in the glep42 thread email covers this already; zmedico already adress Display-If-Profile (namely, a simple portageq extension). What remaining straw men are there for ignoring the portage developers requests? ~harring pgpUt42bTyTFp.pgp Description: PGP signature
Re: [gentoo-dev] draft glep: multi-repo
On Sat, 17 Dec 2005 16:14:15 -0800 Brian Harring [EMAIL PROTECTED] wrote: | What remaining straw men are there for ignoring the portage | developers requests? Asking you to specify how multiple repositories will work before I try to extend the GLEP to support multiple repositories is hardly a straw man argument. *shrug* But if you prefer, I'll change the GLEP to support multiple repositories the way I'd like to see them done rather than the way you'd like. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] draft glep: multi-repo
On Sat, 17 Dec 2005 17:01:59 -0800 Brian Harring [EMAIL PROTECTED] wrote: | Do you need to know how every bit of a car works to drive it? No. No, but I do need to know whether it has manual or automatic gears, and where the steering wheel is. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42 (Critical news reporting) updates
On Sun, Dec 18, 2005 at 01:07:27AM +, Ciaran McCreesh wrote: On Sat, 17 Dec 2005 16:51:05 -0800 Brian Harring [EMAIL PROTECTED] wrote: | Transitioning from single news.unread to N is going to break clients | that expect a single. Yup. | As I said, you're going to break stuff- and you're building it into | your glep out of (aparent) stubborness. No no. I'm just not adding something ill defined and arbitrary to the GLEP to avoid introducing minor possible breakage when some ill defined and arbitrary change is made to Portage. Well, since we're toeing the line, I'll just state your glep is ill defined and arbitrary, it is inflexible and incomplete due to the fact it doesn't take into consideration the existing solutions (namely overlays). Back off the technical double speak insults unless you want others people to get nastier then they are already. | What do you want, another glep amending yours with that one little | detail? Probably won't be necessary... If you're unwilling to make your 'flexible' proposal actually flexible for anything but your stuff (eselect), either the glep is going to be fought tooth and nail or a competing glep is going to come out of this. Bluntly, stop being a tool, users want this feature, stop using it as fodder to fight. | The news glep crosses several groups, collaboration here is required, | meaning *listen* to the folk you're trying to command. Otherwise the | glep *will* go nowhere no matter how much noise you make. And I'm asking you to provide me with a specification of how multiple repositories will work. Without that, there's no way the GLEP can be made to handle multiple repositories. We have overlays already. That *is* multiple repositories. Stop trying to dodge the request by making us waste our time and produce a stand alone repository glep- overlays exist *now*, thus you *do* need to address them *now* else your glep is incomplete. | | If you're going to create and dump a mess on us, I expect it to | | be in the proposal- especially since your proposal is | | intrinsically portage bound. | | There's very little that's Portage bound. As originally requested, | I've tried to keep as much as is reasonably possible *out* of | Portage... | | It's distributed via the portage tree, it's updated by portage, the | check for new news items is *via* portage, and check for news items | prior to merging is done by portage. | | If that truly was your intention, you failed in it.. It's bound to | portage, despite the rhetoric. No no. A Portage bound solution would stick all the code and clients in Portage proper, rather than using Portage merely for hooks as far as is reasonably possible. Word games... You're dodging my point. | Word games suck, instead of playing them you *should* be trying to | address the concerns- iow, what do you *explicitly* need from | portage, What explicitly I need, *if* the GLEP is to specify multiple repository support from the outset, is a specification of how Portage will handle multiple repositories conceptually and a description of the interface that will be provided by Portage. Overlays. The only thing you need is a repo id, the only thing we need is to know what you'll be accessing, what we need to future proof from an api standpoint. | Especially since you've said we're not doing it the way you think | it should work... | | Where have I stated that? My statements thus far about multi repo | were in reference to a glep that missed the target. | | Provide quotes please, or get back to nailing down exactly what you | need portageq wise so we can state do it this way, and we'll shut | up. I'm thinking mainly about Portage externally will use user defined in relation to repository identification. Any specification on multiple repositories that comes from me will have said identifiers being repository designed, simply because I can't see a sane way of handling it otherwise. We've had this discussion once already, but I'll keep hammering the point till you follow it- external repo label is just that, what the user would specify on commandline. emerge --repo blah --rsync (fex). Internal ids are a seperate beast, and a simple solution *now* is that any repo that provides new must bundle an ID. Do that, and portage can made to use it for your news crap. Aliasing (user naming) is something *we* would add as a feature down the line. Why am I stating it as such? Because again, overlays exist now, and your glep is willfully leaving them out in the cold. | You want us to nail everything down for our request, I'd like you to | do the same (especially since we're stuck maintaining whatever you | propose/create). I can't nail down details on multiple repository support until I'm told what Portage will do. Give me a specification for what Portage will do and I'll quite happily make the GLEP work with it.
Re: [gentoo-dev] draft glep: multi-repo
On Sun, Dec 18, 2005 at 01:08:31AM +, Ciaran McCreesh wrote: On Sat, 17 Dec 2005 17:01:59 -0800 Brian Harring [EMAIL PROTECTED] wrote: | Do you need to know how every bit of a car works to drive it? No. No, but I do need to know whether it has manual or automatic gears, and where the steering wheel is. Stop spamming the list with idiot snarky responses, and discuss the issues at hand. Bluntly, others may back down from your shit but I'm not going to. A half baked proposal that is *broken* from the start being dumped on the mess that is portage is not acceptable. If you're not going to fix your glep, state so, stop wasting others time. Just take it to the council and have them ixnay it on the same issues people have continually pointed out. ~harring pgpLhEN9Gct9n.pgp Description: PGP signature
[gentoo-dev] glep 42 (news) round six
Here we go again... Changes:
* We're now supporting overlays, multiple repositories and magic flying
chickens. To do this, we're shoving a whole load of new requirements
onto Portage. Said requirements are documented under `Required Portage
Enhancements`_. I now expect to get heavily flamed by a different set
of Portage developers.
* Allow underscores in names too.
* Change to -mm-dd for GLEP 45 compatibility. Rereremove the
timestamp on the Posted: header.
* Tweak Display-If-{Profile,Installed} to work with multiple
repositories.
* Use ${repoid} rather than magic-chicken for news-*.* files.
* Be specific on how news-repoid.skip can work.
You are encouraged to reply to this thread saying I agree with ciaranm
that repository IDs should not be allowed to contain spaces.
We're getting there... Slowly...
--
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
GLEP: 42
Title: Critical News Reporting
Version: $Revision: $
Author: Ciaran McCreesh [EMAIL PROTECTED]
Last-Modified: $Date: $
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 31-Oct-2005
Post-History: 1-Nov-2005, 5-Nov-2005, 7-Nov-2005, 11-Dec-2005, 13-Dec-2005,
18-Dec-2005
Abstract
This GLEP proposes a new way of informing users about important updates and news
regarding tree-related items.
Motivation
==
Although most package updates are clean and require little user action,
occasionally an upgrade requires user intervention during the upgrade process.
Recent examples of the latter include the ``gcc-3.4`` stabilisation on ``x86``
and the ``mysql-4.1`` database format changes.
There are currently several ways of delivering important news items to our
users, none of them particularly effective:
* Gentoo Weekly News
* The ``gentoo-announce``, ``gentoo-user`` and ``gentoo-dev`` mailing lists
* The Gentoo Forums
* The main Gentoo website
* RSS feeds of Gentoo news
* ``einfo`` and ``ewarn`` messages in ``pkg_setup`` or ``pkg_postinst``
A more reliable way of getting news of critical updates out to users is required
to avoid repeats of the various recent upgrade debacles. This GLEP proposes a
solution based around pushing news items out to the user via the ``rsync`` tree.
.. Important:: This GLEP does not seek to replace or modify ``einfo`` messages
which are displayed post-install. That is a separate issue which is handled
by ``elog`` [#bug-11359]_.
Requirements
An adequate solution must meet all of the following requirements:
Preemptive
Users should be told of changes *before* they break a system, not after the
damage has already been done. Ideally, the system administrator would be
given ample warning to plan difficult upgrades and changes, rather than only
being told just before action is necessary.
No user subscription required
It has already been demonstrated [#forums-apache2]_ that many users do not
read the ``gentoo-announce`` mailing list or ``RSS`` feeds. A solution which
requires subscription has no advantage over current methods.
No user monitoring required
It has already been demonstrated [#forums-apache2]_ that many users do not
read news items posted to the Gentoo website, or do not read news items
until it is too late. A solution that relies upon active monitoring of a
particular source has no advantage over current methods.
Relevant
System administrators who do not use a particular package should not have to
read news items which affect purely that package. Some news items may be of
relevance to most or all users, but those that are not should not be forced
upon users unnecessarily.
Lightweight
It is not reasonable to expect all users to have an MTA, web browser, email
client, cron daemon or text processing suite available on their system.
Users must not be forced to install unreasonable extra software to be able
to read news items.
No privacy violations
Users of the solution should not be required to provide information about
their systems (for example, IP addresses or installed packages).
Multiple delivery method support
Some users may wish to view news items via email, some via a terminal and
some via a web browser. A solution should either support all of these
methods or (better still) make it simple to write clients for displaying
news items in different ways.
The following characteristics would be desirable:
Internationalisable
Being able to provide messages in multiple languages may be beneficial.
Quality control
There should be some way to ensure that badly written or irrelevant messages
are not sent out, for example by inexperienced developers or those whose
English language skills are below par.
Simple for developers
Posting news items should be as simple as is reasonably possible.
Simple for users
Reading relevant
Re: [gentoo-dev] glep 42 (news) round six
I agree with ciaranm (did I really just say that?) that repository IDs should not be allowed to contain spaces. -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] glep 42 (news) round six
Not that my lowly user opinion matters, but I agree with ciaranm that repository IDs should not be allowed to contain spaces GLEP 42 wrote: * Before an ``emerge --ask target`` sequence What, exactly, does this mean? I'm guessing it means between the package list and the prompt, but it's not quite clear. Also, there's a typo in the last line of the News Item Body section: s/may/many/ -- # # electronerd, the electronerdian from electronerdia # pgplMBAjkKt00.pgp Description: PGP signature
Re: [gentoo-dev] glep 42 (news) round six
On Sat, 17 Dec 2005 20:50:43 -0800 John Myers [EMAIL PROTECTED] wrote: | GLEP 42 wrote: | * Before an ``emerge --ask target`` sequence | What, exactly, does this mean? I'm guessing it means between the | package list and the prompt, but it's not quite clear. I dunno, I refuse to use emerge --ask for religious reasons. Feel free to rewrite that bullet point. | Also, there's a typo in the last line of the News Item Body | section: s/may/many/ Not any more there isn't. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] glep 42 (news) round six
On Saturday 17 December 2005 20:57, Ciaran McCreesh wrote: On Sat, 17 Dec 2005 20:50:43 -0800 John Myers [EMAIL PROTECTED] wrote: | GLEP 42 wrote: | * Before an ``emerge --ask target`` sequence | | What, exactly, does this mean? I'm guessing it means between the | package list and the prompt, but it's not quite clear. I dunno, I refuse to use emerge --ask for religious reasons. Feel free to rewrite that bullet point. How about * During ``emerge --ask``, the same as for ``emerge --pretend`` (i.e. after the package list) ? -- # # electronerd, the electronerdian from electronerdia # pgpdJu9AW28mK.pgp Description: PGP signature
Re: [gentoo-dev] glep 42 (news) round six
On Sun, Dec 18, 2005 at 04:15:45AM +, Ciaran McCreesh wrote:
Here we go again... Changes:
* We're now supporting overlays, multiple repositories and magic flying
chickens. To do this, we're shoving a whole load of new requirements
onto Portage. Said requirements are documented under `Required Portage
Enhancements`_. I now expect to get heavily flamed by a different set
of Portage developers.
You forgot the magic mushroom badgers and snake.
* Change to -mm-dd for GLEP 45 compatibility. Rereremove the
timestamp on the Posted: header.
* Tweak Display-If-{Profile,Installed} to work with multiple
repositories.
* Use ${repoid} rather than magic-chicken for news-*.* files.
Drop the magic-chicken crap (especially in light of your comments
about 'professional' news inline in the glep).
Killjoy maybe, but it detracts from the point of the glep.
* Be specific on how news-repoid.skip can work.
Still haven't gotten into specifics, merely a different bit of hand
waving.
You are encouraged to reply to this thread saying I agree with ciaranm
that repository IDs should not be allowed to contain spaces.
TODO: ferringb wants spaces added to the first item on the list. I don't,
because it makes repo id - filename mappings nasty.
* Every repository (including overlays) will require a unique identifier. It
is
assumed that an identifier will be a string consisting of characters from
``a`` to ``z``, ``A`` to ``Z``, ``0`` to ``9``, ``+`` (plus), ``-``
(hyphen),
``:`` (colon) and ``_`` (underscore).
Not really. Just requires your code to be space safe.
You write good code, right? Especially since you need to keep our
path handling safe for osx (/volumes) and for users who do strange
things?
The news handling crap should be able to take spaces- remember the
comments about user aliasing of repostory ID's down the line. I don't
care if the actual metadata/repo_id lacks spaces, but the handling
code must be able to take spaces, as such the requirement that spaces
not be used is arbitrary and uneeded.
* Portage must provide a way for external programs to obtain a list of all
repository identifiers for a given system. It is assumed that this will be
in
the form of a ``portageq`` command (e.g. ``portageq get_repo_ids``).
* Portage must provide a way for external programs to obtain the base path for
a repository with a given ID. It is assumed that this will be in the form of
a ``portageq`` command (e.g. ``portageq get_repo_root gentoo-x86``).
* Portage must extend ``portageq has_version`` to support restrictions to a
given repository ID.
* Portage must extend ``portageq`` to implement a command which returns
whether
or not the profile used for a given repository ID matches a certain base
path
(e.g. ``portageq profile_used default-linux/sparc/sparc64/2004.3
gentoo-x86``).
profile_in_use, maybe.
These extensions are assumed during the following specification.
News Item Identities
Each news item will have a unique identifier. This identifier will be in the
form ``-mm-dd-short-name``, where ```` is the year (e.g. ``2005``),
``mm`` is the month (``01`` through ``12``) and dd is the day of the month
(``01`` through ``31``). The ``short-name`` is a very short name describing
the
news item (e.g. ``yoursql-updates``), consisting only of the characters
``a-z``,
``0-9``, ``+`` (plus), ``:`` (colon), ``-`` (hyphen) and ``_`` (underscore).
News Item Directories
-
Each news item will be represented by a directory whose name is the same as
the
news item's identifier.
The directory will contain a file named ``-mm-dd-short-name.en.txt``,
which
contains the text of the news item, in English, in the format described below.
If a news item is translated, other files named
``-mm-dd-short-name.xx.txt``
(where ``xx`` is the ISO 639 [#iso-639]_ two letter country code) will also be
provided. However, only the English version of a news item is authoritative.
This anglocentricity is justified by precedent [#glep-34]_.
News Item Files
---
A news item file is a text file, encoded using UTF-8 [#rfc-3629]_ for
compatibility with and for the same reasons as existing Gentoo documentation
[#docs-policy]_ and the tree [#glep-31]_.
News items should be signed with a detached GPG signature: ::
why should vs must?
Should leaves open the possibility for a tree compromise and a news
item with Very Bad(tm) instructions stuck into it.
Moving towards getting the whole tree signed, introducing new
components that aren't required signed works against that.
News Item Headers
'
The following headers describe the purpose and format of the news item:
``Title:``
A short (maximum 44 characters) descriptive title. Mandatory.
``Author:``
Author's name and email address, in the form ``Real Name [EMAIL
PROTECTED]``.
Re: [gentoo-dev] glep 42 (news) round six
On Sat, 17 Dec 2005 21:50:47 -0800 Brian Harring [EMAIL PROTECTED] wrote: | Drop the magic-chicken crap (especially in light of your comments | about 'professional' news inline in the glep). Eh, there aren't any magic chickens in the glep. | Not really. Just requires your code to be space safe. | | You write good code, right? Especially since you need to keep our | path handling safe for osx (/volumes) and for users who do strange | things? The problem isn't my code. My code's fine. So is eselect. The problem is people who write their own handler scripts to suit their own needs, and then get nastily bitten because they don't realise we're allowing spaces in filenames. Do you remember that Apple installer program that ended up in effect doing rm -fr / if you tried to install a particular OS X program to a volume whose name contained a space? | * Portage must extend ``portageq`` to implement a command which | returns whether or not the profile used for a given repository ID | matches a certain base path (e.g. ``portageq profile_used | default-linux/sparc/sparc64/2004.3 gentoo-x86``). | | profile_in_use, maybe. Mmm, that use looks too much like USE. *shrug* Exact names don't matter at this stage anyway. | News items should be signed with a detached GPG signature: :: | | why should vs must? | Should leaves open the possibility for a tree compromise and a news | item with Very Bad(tm) instructions stuck into it. | | Moving towards getting the whole tree signed, introducing new | components that aren't required signed works against that. I don't want to introduce any signing requirements that we don't have already. When signing for everything else becomes mandatory, signing for news would be too. If I make this a 'must', someone will ask me to specify how we're handling the Gentoo keyring... | ``Revision:`` | Initially 1. Incremented every time a non-trivial change is | made. Changes which require a re-read of the news item should | instead use a new news item file. Mandatory. | | non-trivial changes that don't require a re-read sounds like a | contradiction. Clarify, especially since portage will mark this as | read _once_ and only once. Hrm, word it as Changes other than minor formatting tweaks, or remove non-trivial? | The following headers are used for filtering: | | ``Display-If-Installed:`` | A dependency atom or simple package name (for example, | | Drop the 'simple package name'; it still is an atom. Ok. | This isn't incredibly useful if ranged versions are ever introduced. | Ammending the glep for that seems stupid, looser language might be | wise. What's the syntax for ranged versions? And how do they differ from SLOT versions? | | .. Note:: When performing package moves, developers must also | update any | relevant ``Display-If-Installed`` headers in news files. | | Grounds for someone to get off their ass and do some work, but this | should be automated in some fashion- specifically detection of it | (auto-updating won't work with signing). Moving packages in general requires a re-sign anyway. I'm guessing that epkgmove will handle this, if it ever starts working again... | That's an implementation note, but I'm bringing it up since the time | to do the filter/cache instantiation is during portage initialization | (yes it sucks, but your stuck with stable)... so start thinking about | ways to make it fast, since python -c'import portage' is the slowest | part of portage queries Looks like I might have to do that thing in Python rather than bash then... | News Item Quality Control | - | | There have been complaints regarding the comprehensibility of some | upgrade notices and news items in the past. This is | understandable ??? not every Gentoo | | '???' ? It's a dash. It'll show properly in the HTML version. | | .. Note:: A previous draft of this GLEP allowed news items to be | sent to ``gentoo-core`` instead of ``gentoo-dev``. It is possible | that a situation may arise where this will be necessary (for | example, a security update which must break backwards compatibility | and which cannot be revealed to the public before a given date). | | Drop that and just state that -core doesn't fly sans security | consideration; referencing one of the previous 5 versions isn't | needed (yes it's minor, but it's uneeded info). Ok, the entire Note's gone. If we ever really have to do a nasty update for security reasons, whichever poor shmuck ends up handling it should be smart enough to know what to do... | We generate a tree every 30 minutes. You aiming for every update, or | for less frequent (once an hour fex)? | | Matters due to the fact rsync tree generation has a window it must | not overrun- minor but continuing the lets be explicit goal of | yours. Once an hour would work fine. On the other hand, the merge is just copying a few small files -- time-wise, it's less than generating the
