Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two
On Sat, 5 Nov 2005 00:58:14 + Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > Feedback from people who have something useful to say would be very > much welcomed, assuming of course that they've read the GLEP. I think you might be missing a 'not' from the first Requirements section. Unless you're secretly pushing an evil agenda to make everyone use Debian by breaking everyone's Gentoo systems, that is. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: new developer Joshua Nichols (nichoj)
On Wed, 23 Nov 2005 06:05:09 -0700 Duncan <[EMAIL PROTECTED]> wrote: > If it's so useless, after > all, would someone have spent the time to post it? Apparently someone did. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] contents of /dev after initial installation
On Fri, 02 Dec 2005 03:35:23 +0100 Matthias Langer <[EMAIL PROTECTED]> wrote: > revealed that there are in fact hundrets of premade device nodes in > the /dev directory. And this is not only true for the box where i > discovered this, which was brought up from a 2004.x cd, but also true > for the box where i just installed gentoo from 2005.1-r1. > > Is there any reason for this ? Not all systems use udev or devfs. Plus, it's nice to be able to boot the system when your dynamic /dev management fails for whatever reason. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] contents of /dev after initial installation
On Fri, 2 Dec 2005 12:45:00 +0900 Georgi Georgiev <[EMAIL PROTECTED]> wrote: > I don't need a fully populated /dev to get a working shell with > init=/bin/bash on the kernel cmdline. And at that point it is easy to > run /dev/MAKEDEV and get whatever devices are needed for > troubleshooting. Still more effort than booting into a system that is pretty much fully-functional already to fix it. > I of course assume that if the dynamic /dev management fails, then we > need to *recover* instead of trying to get the system up as usual. > And I also assume that the init scripts will anyway tell me "fatal > error: give root password for maintenance or Ctrl-D to continue" if I > have something vital missing from /dev. See above. And that still doesn't address the issue that some people don't even want dynamic device management in the first place. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Sun, 8 Jan 2006 01:15:22 +0100 Carsten Lohrke <[EMAIL PROTECTED]> wrote: > I think I'm too late for this month, but want to put it on the table > before I forget about it. I'd appreciate a three months moratorium, > disallowing everyone to add new packages to the tree (despite new > dependencies of existing packages), so everyone is forced/asked to > put his energy in existing ebuilds, especially unmaintained ones. > Sort of spring-cleaning, because parts of the tree look like a dump. And I'd like to propose disallowing everyone from proposing the wrong solution to the wrong problem for the next three months. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] sed vs gsed
On Wed, 25 Jan 2006 00:14:13 +0100 "Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote: > Comments about this? (Please don't tell me to do a GLEP about this) We've discussed this several times in the past, and every time the answer has been that in the ebuild environment `sed` is gnu sed-4. It's the only sane way to do things, since certain other platforms ship retarded versions of sed. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: emerge snapshots
On Fri, 27 Jan 2006 16:08:40 -0700 Duncan <[EMAIL PROTECTED]> wrote: > Neither here nor there, but for some reason, I prefer "emerge -NuD > world". =8^) Especially since you just said yourself it was irrelevant, I'm at a loss to see quite why you felt the need to tell us this. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 47: Creating 'safe' environment variables
On Fri, 10 Feb 2006 01:30:40 -0700 Duncan <[EMAIL PROTECTED]> wrote: > OK, despite the given reasoning, I found this distracting. Perhaps > this is one of Ciaran's English readability suggestions, but is there > a reason not to s/segment/tuple/g ? That seems to me more accurate, > "segment" is more accessible English to non-programmers than "tuple", > and it should cure the distraction problem I experienced. Of course, > it could be just me... Probably because he means 'tuple', and not 'segment'. The two are very different things. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites: app-editors/gnotepad+
On Fri, 17 Feb 2006 01:14:39 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: > http://upload.wikimedia.org/wikipedia/commons/9/9e/DoNotFeedTroll.jpg Err, what? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] beep-media-player removal: 04/03/2006
On Fri, 24 Feb 2006 03:02:32 + "George Prowse" <[EMAIL PROTECTED]> wrote: > No, BPMx and Audacious are two different things Err, I think that might have been his point. > > http://audacious-media-player.org/FAQ#1.4 > > On 22/02/06, Diego 'Flameeyes' Pettenò <[EMAIL PROTECTED]> wrote: > > > > On Wednesday 22 February 2006 19:34, Stephen P. Becker wrote: > > > Ugh, it looks like this new 'BMPx' branch uses gstreamer. Is > > > there no way to keep the good old clean, working version of BMP > > > in portage? > > That is audacious. > > > > -- > > Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ > > Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE > > > > > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 10:47:58 -0600 Lance Albertson <[EMAIL PROTECTED]> wrote: > We all know that > something that stupid needs to be delt with quickly. So you're agreeing that someone needs to be able to act should a package maintainer screw up sufficiently badly, and the obvious candidate for that role is the QA team. The ability to overrule package maintainers doesn't, and shouldn't, mean that they'll go around doing so willy-nilly, but it should be there as a last resort should it be necessary. (Yes, I'm taking that sentence out of context, but the fact that it comes up at all says something, to my mind.) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] bug #20201 and bbapm
On Mon, 27 Feb 2006 18:54:13 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: > yet as a member of maintainer herd haven't dealt with that > properly for quite an extensive period of time Sounds like someone still needs to read herds.xml. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 21:12:22 + Stuart Herbert <[EMAIL PROTECTED]> wrote: > On Mon, 2006-02-27 at 20:54 +, Ciaran McCreesh wrote: > > My point is that that's a nasty QA bug that's relying upon input > > from Stuart to be fixed. > > I'm afraid you've been mis-informed. The PHP herd has provided a set > of default USE flags to go into the profiles, and there's a comment > at the bottom of the bug clearly stating that they're currently being > tested. That's not a fix. That's a workaround. The PHP ebuilds are still broken; all that's changed is that the breakage isn't apparent on a default install. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 16:08:05 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: > When and where has been the following change discussed and who > approved that? > > http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo According to my recollection, it was discussed between members of QA and devrel. According to the CVS logs, it was committed by a member of devrel, at QA's request. You can't pass it off as a QA project conspiracy, since they didn't make the change. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 16:42:30 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: > Punting every single piece of broken sh*t from the tree requires > notifying everyone on -dev ml and allowing a period of time before > it's actually done, so silently changing/stating policies is a very > broken practice. This wasn't a silent change. It's been policy for as long as I can remember; it was just made explicit in the devrel documentation with that commit. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 17:38:10 +
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> if [ "${IS_UPGRADE}" = "1" ] ; then
> einfo "Removing old version ${REMOVE_PKG}"
>
> emerge -C "${REMOVE_PKG}"
> fi
Uh, what the fuck is that doing in an eclass ?
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 18:59:49 +0100 Patrick Lauer <[EMAIL PROTECTED]> wrote: > (and this is valid for all emails to technical lists,) > please save us some time and many emails by stating what is wrong when > you show a QA violation. This is a technical discussion list, and as such it is fair to assume that anyone getting involved in a discussion on a particularly topic knows enough about said topic to understand what is going on. If you can't see what's wrong with the snippet he gave, then you shouldn't be in the discussion, and, frankly, probably shouldn't have commit rights to the tree either. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 20:27:01 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: > Once again, don't invent problems, please. Just because you don't see a problem doesn't mean it's not there. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Fri, 3 Mar 2006 21:47:22 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: > Please, until something is clarified/some consent reached, avoid > changing the docs w/ funny stuff like "just flip a coin"... > > http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?root=gentoo&r1=1.31&r2=1.32 > > What's the above again? QA policy? How does user benefit from > flipping a coin wrt choosing a functionality? Sigh... :/ It gets the point across effectively. I don't see your problem. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Fri, 3 Mar 2006 22:27:45 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: > What kind of point does it get across, exactly? That you must choose one flag, or set of flags, to take precedence in such situations, but that how you choose is quite immaterial. If there is an obvious choice then use it, else pick one some other way. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Fri, 3 Mar 2006 23:31:49 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote: > Yeah, that's a wonderful message. Let users choose, they are not > idiots and such policy does more harm than good. Period. You're completely missing the point here. The user has a choice, but if his set of choices doesn't make sense for whatever reason, you have to decide on some sane way to configure the package. How you come to that decision is irrelevant, hence the 'flip a coin'. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] x86-fbsd keyword in main tree?
On Thu, 09 Mar 2006 10:20:33 -0500 Alec Warner <[EMAIL PROTECTED]> wrote: > Basically portage expands $ARCH into use ( so > x86-fbsd has ARCH x86, and would get "x86" in use, which IMHO, isn't > that horrible ). However, you also don't get x86-fbsd shoved into > USE, so you have to inject it elsewhere, and then users could do > something stupid like -x86-fbsd in make.conf, and unset their ARCH > flag = bad. The profiles currently in the overlay set ARCH=x86-fbsd. Whether that's right or not is another debate, but it invalidates that particular problem. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] x86-fbsd keyword in main tree?
On Thu, 9 Mar 2006 15:29:23 +0100 "Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote: > To bring ~x86-fbsd keywording in main tree, we mainly need to move a > true profile in the tree, not a dummy one, mark it as indev and start > the keywording. (I've already cleaned up the default-bsd/fbsd profile > so that it does work with the current base/ profile. > As long as virtual/libc is not in the dependencies, it shouldn't > trigger any kind of problems to leave the sys-freebsd category in the > overlay, if we really need to start needing that, I'll see to make > the ebuild quality level. My main objection here is "If it's worth doing, it's worth doing properly." I'd rather see the keywords and system ebuilds merged at the same time, so we don't end up with some half-system that has keywords in the tree but can't be installed. > It's not going to be a quick thing, as I'm mostly alone with > Gentoo/FreeBSD right now (help is always welcome), but times are > mature so that I can provide a decent experience to users. > > Can anybody name a showstopper to this? As far as I'm concerned the main reason this has been almost exclusively in overlay for so long is that we can rework things much more easily without worrying about breaking backwards compatibility or upgrade paths. If it's in a state where that's not likely to be an issue any more then I'd be in favour of merging it, as long it's done right. That in itself will of course be a non-trivial task, but I can awake from my BSD-related hibernation to get it done if it's reckoned to be a good idea and unlikely to break anything. On the other hand, I don't want to do this if there are serious objections from other devs, so any opinions from outside gentoo-alt are welcome. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [Last Rites] NVU
On Sat, 18 Mar 2006 21:13:29 -0600 "Jory A. Pratt" <[EMAIL PROTECTED]> wrote: > If > noone has any complaints I will p.mask Wed. March 21 and remove 30 > days later. Do you mean Wednesday, or March 21st? Or were you planning on masking it next year? -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] virtual/acl
We have a fair number of packages in the tree (57 someone said, but a non-trivial number) which depend upon sys-apps/acl for ACL support. Since the packages needed for this differ between platforms (sys-apps/acl is for linux only), if noone has any reasonable objections I will be adding a (new-style) virtual/acl for these packages sometime in the next week or so. This email brought to you on behalf of Flameeyes. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] virtual/acl
On Sun, 02 Apr 2006 13:41:25 -0400 Ned Ludd <[EMAIL PROTECTED]> wrote: > In your own words what benefit does this have over > kernel_linux? ( acl? ( sys-apps/acl )) It moves all of the platform-conditional voodoo into one place, which helps maintainability and will greatly reduce the work involved in adding a new port that may use a different package for ACL support. We had a lengthy discussion on this topic between the *BSD and portage teams some time last year, and the consensus was that the correct solution was to move all the deps that change between platforms into one place (the new-style virtual category). I haven't seen anything change that would make for a different conclusion were the same discussion to happen now. Especially when more packages appear which are widely depended upon and change between platforms, and more platforms are added, this approach will greatly reduce the maintenance burden that Gentoo/Alt projects place upon the main tree. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] adding a code of conduct
On Mon, 03 Apr 2006 21:40:54 -0400 Ned Ludd <[EMAIL PROTECTED]> wrote: > Umm ok. I've decided that root is root no matter how you look at it > and it's not worth getting into a vertical pissing contest over. So this is effectively an admission that infra intends to use its position of trust to unilaterally enforce its members' will upon the developers as a whole. I shall make a note not to disagree with any of you in the future. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] adding a code of conduct
On Mon, 03 Apr 2006 22:23:49 -0400 Ned Ludd <[EMAIL PROTECTED]> wrote: > don't be a troll man. If that comment appears to be a troll, I will assume that I misinterpreted the mail to which it was a reply. Could you enlighten me as to what I should have taken from it instead? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
On Fri, 28 Apr 2006 12:03:29 -0700 Chris White <[EMAIL PROTECTED]> wrote: > Ok, but most "active contributors" are people that submit ebuilds to > devs and know nothing about the structure/policy/whatever about > ebuilds. If you're not a dev, you're probably not going to worry > about revision bumps. If you're a dev without alternate arches, > you're probably not going to know about how other arches can get > screwed by improper pic handling. > > To conclude, active contributors are generally in a focused > environment. The quiz is there to help show them the global way of > handling things. That problem can be solved by giving new developers access to a 'sandbox' branch of the tree, and have a more experienced dev merge their changes into the live tree having checked them for sanity. Once they've proved themselves there, they can be given access to the main tree if appropriate. Of course, this relies upon using a VCS for the tree that handles branches and merging sanely, which should be doable with Subversion if the issues it had last time this was tested have been or can be resolved. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ACCESS DENIED during emerge
On Fri, 28 Apr 2006 15:41:48 -0400 (EDT) "A. Khattri" <[EMAIL PROTECTED]> wrote: > > In writing and testing a new ebuild, I ran emerge as root and got > ACCESS DENIED errors when it tried writing two config files into /etc. > > Do I need to do something special for config files in an ebuild? http://dev.gentoo.org/~plasmaroo/devmanual//general-concepts/sandbox/ http://dev.gentoo.org/~plasmaroo/devmanual//appendices/common-problems/#handling-access-violations -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] ANNOUNCE: Paludis 0.2.0
Ok, we're now officially admitting that Paludis exists (really this time), and is fit for an initial public release. Paludis is a library providing ebuild-related utilities together with a simple command line client. It is not a Portage rewrite, nor is it a Portage replacement, although it could be considered to be on its way to becoming a Portage alternative. Many of the features in Portage are not present in Paludis. Some of these features will appear in Paludis at a later date; some will not. Paludis is not Portage compatible, and should not be used on the same ROOT as Portage. Paludis will rape your dog. The homepage is at [1], and includes a HOWTO explaining how to set up a chroot built with Paludis. Note the bug tracker and mailing list; discussion of this lot on Gentoo lists is highly discouraged since it's not supported. The source can be found at [2] for those too lazy to use Subversion. Bug reports go via the bug tracker, preferably only after having discussed them in #paludis. So far most bugs we've found have been user or ebuild screwups. Feature requests and requests for doing stuff that Portage does are not welcome unless they come with a decent patch or are actually easy to implement rather than just looking like it; we are at the "make it more or less sanely usable" phase, not the "make it nice and shiny for end users" phase. Ricers will be terminated. For a list of differences between Portage and Paludis, see [3]. The list is not complete, nor does it attempt to be, but provides some points of interest that are intentionally different. Some of these are missing Portage features, while some are fundamental differences in design. All are subject to change without warning or reason. Paludis has been used to install at least one bootable system, complete with Xorg and Fluxbox. There was a full moon at the time. It cannot install Gnome because Gnome's deps are broken. It cannot install KDE because no-one can be bothered sitting and watching Qt compile. [1]: http://paludis.berlios.de/ [2]: http://developer.berlios.de/project/showfiles.php?group_id=6360 [3]: http://paludis.berlios.de/PortageDifferences.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Discussion
On Tue, 09 May 2006 18:27:45 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > Then again, I'm missing context because people have this weird thing > about abstractly bringing up issues without discussing the actual > problem. The context is that I added profiles/repo_name to the tree ~5 days ago, in order to properly take advantage of functionality available in a certain package available in the tree (sys-apps/paludis). It's 7 bytes and doesn't adversely affect anything, so I didn't deem it particularly worth making a fuss about. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Paludis and Profiles
If noone has any strong reasonable objections, I'd like to add a Paludis profile to the tree. This would use Paludis as the default provider for virtual/portage (which is a less than ideal name, but that is another discussion entirely), and provide ebuild devs with a place where they can try out some of our profile enhancements should they want to. It is worth noting on the last point that most of these are long-standing Portage feature requests, at least some of which are planned for inclusion in Portage at some point in the future. This would allow devs access to them earlier, as a sort of testbed. The next question is where to put it. The options as I see them are under default-linux/x86/ or in a top-level paludis/ a la hardened, selinux, embedded, and the like. The latter is easier to exclude for those worried about tree size, though the impact there should be minimal. Neither way produces significantly more duplication, since we can make use of multiple profile inheritance. If anyone has any preference or other input, I'd like to hear it. That's my proposal. The benefits I like to think are obvious. The drawbacks are, as far as I can see, in tree size, which should be minimal. Those concerned about local tree size can exclude it, and for size on the mirrors it's trivial compared to the rest of the tree. Comments? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Thomas Cort wrote: I don't understand the logic behind putting it under default-linux/x86/. > Is palidus Linux/x86 only? Could you explain why default-linux/x86/ is a good option? It's not -- it's currently confirmed to work on x86, amd64, sparc, mips, alpha, and hppa. I don't believe it is a good option, but some people may object less to a profile hidden away there than one at the top level. *shrug* -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Brian Harring wrote: So... short version, introduction of the profile allows for curious users to get bit in the ass by intentional dropping of compatibility (profile level changes are one thing, changing the ebuild standard is another). In light of that, why should it be demoed in the tree where the only use of it is to bootstrap a new installation? Just overlay it, y'all should be maintaining an overlay fixing ebuild incompatibilities anyways. This I see as a non-argument. We imitate enough of Portage's idiosyncracies to support every ebuild with which we've tested it, so the ebuild format is for all intents and purposes the same. Sure, a few internal variables have different names, but those are the ones that ebuilds generally shouldn't be using, and if there is a legitimate case where they are used, we emulate it. And it would have uses beyond bootstrapping a new installation-- for example, say, running a system exactly as any other profile is used. The gain of the profile is that you can do a few new tricks for folks doing boostrapping experiments- why not just introduce an ebuild that sets up the new profile in a temp overlay? No, the gain is that one could sanely run a Paludis-based system without needing an external overlay, and without having to update said overlay whenever the base profiles in the tree change. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Christian Hartmann wrote: Oh lovely. - If noone has any strong reasonable objections, I'd like to add a $ians-playground profile to the tree. Furthermore I will start to keywording ebuilds with the new ~fridge keyword I just invented. I'll take that to mean "no objection based in a technical argument" then. Thanks. Looking at the comment left for end-users on the paludis homepage [1] I'm still wondering why paludis is not package.mask'ed as it's known to break users systems. If you're going to complain about it because the website is out of date, I can p.mask half of base-system if you like. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Christian Hartmann wrote: It's not about the size or the number of files. We have got enough - let's call it $stuff - in the tree. I'd really like to see valid and reasonable things added to the tree. - Adding things just because someone thinks it would be funny to add it to the tree can't be the way gentoo wants to go. If I were adding it because I thought it would be funny, I would have done so by now. The very fact that I mailed -dev first should be indication enough that I think it's a reasonable addition and therefore want to do things properly. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Alec Warner wrote: I would prefer to see the profile you are commiting then; do you have a link? I haven't written it yet. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Diego 'Flameeyes' Pettenò wrote: You're just FUDing this and you know, the changes are rather minimal, and all directly handled by me (the BSD team), not handled down to maintainers at all. They're rather minimal, and still an order of magnitude larger than what I'm proposing here. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Brian Harring wrote: Bluntly, why should the tree be modified for a minority? Being generous, lets pretend y'all have 300 users- why should incompatible changes be added to the tree (say 300k users) that can bite 299,700 users in the ass for the benefit of 300 users? N parent inherited profiles *is* a change that can bite users in the ass, and it's not an obvious incompatibility unless you know it exists. By this logic, let's remove all the default-bsd, default-darwin, embedded, arm, and sh profiles. They're only used by a tiny minority, and switching an x86/linux system's profile to one of them will hork things majorly. I'm really not seeing your argument here. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Diego 'Flameeyes' Pettenò wrote: A profile in the tree has to be supported by someone. It will be supported by me, and the other devs involved with Paludis. It's also more likely that people would try it out without knowing what they are going to open. So we will add a big fat README, as with all the other experimental / possibly broken profiles, warning users. If it's in portage, it's more likely that users won't look at it deeply and just think that "it's portage, so goes to gentoo bugzilla". There's enough precedent in the tree for specifically telling users to file bugs elsewhere that I don't see this as a great problem. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Tue, 16 May 2006 22:59:59 +0200 "Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote: > Okay, then I suppose you might want first to create a project to > handle the profile and the whole bugs load that might come out of > that. Does every profile need a project to maintain it now? That's never been the case as far as I was aware. If people want a project though, I can create one. > And make sure that bug-wranglers and all the teams are well > informed how to identify people using paludis and where to redirect > all those bugs to (so you need an alias on Bugzilla I'd say). Jakub: Any bugs where the user is using a paludis profile go to [EMAIL PROTECTED] for now. Since profile is among the information we routinely ask for on bug reports, identifying them shouldn't be a problem. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Tue, 16 May 2006 23:14:53 +0200 Jeroen Roovers <[EMAIL PROTECTED]> wrote: > This should not be a side note IMHO. If that profile is in the tree, > who in Gentoo will support it? I will. > Does the Gentoo Project not support the > entire tree all of a sudden? There are plenty of ebuilds in the tree marked as unsupported by gentoo. Probably some profiles too, though I can't name them for certain off the top of my head. > 1) Is bugsy ready for this, with appropriate categories in place? Paludis-related bugs can be marked as invalid and the user directed to Paludis' bug tracker on berlios.de. Alternatively, if our friendly Bugzilla admins want to create categories I won't complain. I don't see a need for it though. > 2) Is there an alias addy for Paludis related issues, so that Paludis > users can communicate with members of some Paludis profile team for > support? For issues related to Gentoo packaging of paludis, bugs can be filed to the ebuild maintainer listed in metadata.xml. For other paludis-related issues, there are mailing lists mentioned on the web site. > 3) Is documentation support in place to refer Paludis profile users to > when they fail to understand "reason" and demand Gentoo support for > issues with the Paludis profile? http://paludis.berlios.de/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
OK, since several people have asked what is going to be in this profile if it gets added, i had in mind something like the following (all filenames relative to gentoo-x86/profiles/): === paludis/deprecated: # DO NOT USE THIS PROFILE WITH PORTAGE. # This profile is intended for use with the Paludis package manager, # and requires features that current Portage versions do not support. # If you attempt to use it # with Portage, things *WILL* break. You have # been warned. # # paludis: ignore this paludis/packages: -*>=sys-apps/portage-2.0.51.22 *sys-apps/paludis paludis/virtuals: virtual/portage sys-apps/paludis paludis/package.mask: =sys-libs/glibc-2.4-r1 paludis/x86/parent: ../../default-linux/x86/2006.0 .. paludis/amd64/parent: ../../default-linux/amd64/2006.0 .. === The deprecated notice should address the concerns of those worried about people switching a Portage system to use one of these profiles, as it would then spit out a hard-to-miss notice upon attempting to do anything. Additionally, at present anyone using the sub-profiles with Portage would get a profile identical to the default-linux ones, due to Portage only considering the first line in parent. Possible additions at a later date could involve use.force for profiles where appropriate (the 'ip28' use flag is an obvious example), as well as package.use.mask being used for per-package USE combination restrictions. However, Portage at the moment ignores the files involved, so they do not affect the issue of Portage attempting to use one of these profiles. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 12:14:37 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > Using the normal profiles would also establish paludis as a possible > replacement of portage as primary package manager. Refraining from > doing so disqualifies paludis from becoming a replacement for > portage. As the only point in adding a secondary package manager is > the possible replacement of the current primary package manager, I > see no point to make any paludis directed changes to the tree. Using the normal profiles isn't an option unless they're changed to include virtual/portage in the system set instead of sys-apps/portage. That's the key change we're interested in here -- that the system set not pull in portage when paludis is being used instead. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 13:40:18 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > Is there a problem about both of them being there? You can't use both on the same ROOT. The VDB format is subtly different. > I don't see a problem in changing the profiles to include > virtual/portage though where portage is the default provider. It is a > change unrelated to paludis, and would allow easier development of > any alternative package manager. This could be a viable alternative if the paludis profile is shown to be a no-go. A seperate profile would make things easier from a bug-wrangling point of view, since it would be easier to determine when a bug may be caused by using paludis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 09:42:50 -0400 Chris Gianelloni <[EMAIL PROTECTED]> wrote: > I would say it wouldn't hurt to start a project for ensuring Paludis > support in the Portage tree. It would give a bit more credibility to > your cause. The problem that I see with this is that it would tend to reinforce the view that Paludis is becoming an officially supported package manager, which at the moment at least it isn't. If people are amenable to the idea though, I'm quite willing to set it up. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 15:25:08 +0100 "George Prowse" <[EMAIL PROTECTED]> wrote: > Why risk anything by changing the tree to suit the package? We're not risking anything, except upsetting a few people. We're not changing anything either, just adding a few files. > It just > seems like asking for trouble. The overlay ability is there for a > reason. Yes, to work around a lack of multiple repository support. It's not there to try to mix profiles between repositories. > Paludis isn't being used and should be kept out of the sphere > of users use until it is usable, wont break systems and is > trustworthy enough to be near the tree It is, it is, it won't unless the user screws up (as with, say, Portage), and it is. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 15:57:51 +0100 "George Prowse" <[EMAIL PROTECTED]> wrote: > Any adding is increasing the risk. No it's not. The only risk comes from the user choosing an inappropriate profile for his system, which is already present. > So good working practice is to introduce a variable where breakages > could come from two directions rather than stick with what works? Let > the project mature before asking for changes from the Gentoo side. That paragraph makes no sense. I don't see what you're trying to say. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 17:13:31 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > At this point I don't see that paludis is ready for such thing. In > any case I think that optimally a package manager does not require > its own profile. It doesn't require its own profile. What does require a new profile is sanely running a paludis-based system without needing to have Portage and all its dependencies installed. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 17:29:11 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > > The problem that I see with this is that it would tend to reinforce > > the view that Paludis is becoming an officially supported package > > manager, which at the moment at least it isn't. If people are > > amenable to the idea though, I'm quite willing to set it up. > > In my opinion if paludis is not aiming to become an officially > supported package manager there is no point in changing the tree to > that in the first place. Note "at the moment". We want paludis to be a viable alternative to Portage for most users, and part of that aim requires having an available profile that doesn't bring Portage into the system set. An "officially supported" package manager is a pretty vague term anyway ... there's a group within Gentoo that will support it, and groups that won't, as with any other part of the tree. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 17:39:02 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > Wouldn't the introduction of the virtual not fix that. This > introduction could be done independent of anything related to > paludis. The introduction of such a virtual would also help other > package managers like pkgcore. That would address some of the immediate concerns, but not any longer term issues -- the default provider in all profiles would still be portage, which requires nasty hackery at system install time, for a start. I'd view changing the system dep to the virtual as a good thing in itself, but not a substitute for a profile in the tree. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 17:37:07 +0100 "George Prowse" <[EMAIL PROTECTED]> wrote: > What it is saying is why introduce anything or change anything just > for your package? Why introduce the possibility of a problem on > either the program or the tree side? Profile changes are made all the time for the benefit of a single package in the tree. From that point of view this is no different. > So far you have failed to give one proper reason for why a change > should be made. Sure I have. Try reading the initial mail. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Paludis and Profiles
On Wed, 17 May 2006 16:28:21 + (UTC) "Duncan" <[EMAIL PROTECTED]> wrote: > Herein lies the crux of the problem, IMO. Regardless of all the other > arguments made, I simply cannot believe it is reasonable to ask that > Gentoo devs give their blessing to add to the tree something that > hasn't yet even been written, let alone tested not to break anything > with existing portage. The initial request was for any objections to the principle. Since people asked for a concrete example of what was going in, I provided it. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Paludis and Profiles
On Wed, 17 May 2006 21:17:55 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > No, these packages are available to paludis, but not to portage. > Basically making a case for the use of paludis. I don't think that > the decision to replace portage should be made in that way. To reiterate here, we're not proposing introducing any paludis-specific features into ebuilds. Only profiles, and those profiles wouldn't provide anything that would provide users who wouldn't otherwise want to use paludis with any incentive to switch. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 22:53:47 +0200 Wernfried Haas <[EMAIL PROTECTED]> wrote: > > The arguments are getting more and more "creative". It's almost > > like asking what we will do when gcc turns into a commercial > > product. > > The package manager is a central piece, if we ever want to change our > package manager we really should think about problems like that. So's the toolchain. > > Please try to stay realistic and don't invent strange new > > theoretical problems. > > Better safe then sorry. Better to stick to reality than invent pink elephants to back up a completely baseless assertion. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 20:56:14 + [EMAIL PROTECTED] (Tim Yamin) wrote: > Well, if you're going to have a package manager that delivers the > same result as Portage it must therefore work with Catalyst... Paludis can produce the same end result as Portage. The reason it won't work with catalyst is that the interface is different. Once again, this is going far beyond the scope of the initial discussion. I'm not saying that Paludis should replace Portage, nor that it should be an "officially supported package manager". The question is simply one of whether I can add a top-level paludis profile without people complaining overmuch, or whether I have to go through the arch teams and make sub-profiles in 4 different places under default-linux/. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Given the sheer volume of impassioned response, regardless of any technical arguments, I'm dropping the top-level profile idea for now. Several architecture teams have expressed an interest in creating sub-profiles under their own, however, and I'll be working with them to get those implemented. Perhaps I'll revisit the top-level idea at a later date when all the fuss has died down. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 09:19:58 +0200 Jochen Maes <[EMAIL PROTECTED]> wrote: > 1) If Paludis has no business in replacing portage on systems (shame, > if it's better/faster it should) why are we having this discussion. > I understand that you need a profile and with an overlay you need to > copy the profiles dir (the whole profiles dir) but be serious that's > only So my question would you be able to do tests without changing > the official tree by copying the profiles dir in an own overlay. We could put profiles in an overlay, but it would require adding support for inheriting profiles relative to another repository path rather than relative to the current directory. Doable, but another place to be incompatible with Portage, so something I'd like to avoid having to do if possible. > 2) If Paludis will be installed on a system to test, and installs > packages, will portage be aware of that installation, and will it be > able to remove it (meaning Paludis changes the portage VDB correctly > when needed). (i've seen you explain that Paludis can read it but not > that it can write it correctly) Paludis can read a Portage VDB last time I tried, but a Paludis-generated VDB will confuse Portage. > 3) If using an own binary format will there be an extracter for it > that isn't part of Paludis? Yes; it's called tar. > 4) Will Paludis ever become a Gentoo Project? Doubtful, barring some rather drastic changes in Gentoo and the way its projects are handled. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 12:18:41 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > If you really really need to have a profile, it might be discussable > to have no-portage profiles, that do not include portage or python in > system. These however must still be portage compatible, and > independent of a package manager. In the arch-specific subprofile case, we'd likely be dropping any features that would cause Portage to choke, and simply changing the system set and virtuals around. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On Thu, 18 May 2006 12:49:29 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > Adding profiles is technically broken. How? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 15:26:06 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > Then copy the bloody profile, or temporarilly add some magic in > paludis that ignores portage and python deps. Not that hard to do. > While not so beautiful it can easilly be removed at a later stage. And if something really does require python? > How far does that spread? Is this only for packages merged by > paludis, or does it spread? And what reasons are there for paludis > not to have a vdb format that will not confuse portage. A VDB entry created by Paludis can't be read by Portage. A VDB entry created by Portage can. > It is very important that package managers coexist with portage. This > allows testing of that package manager, but also the testing of a > package / eclass on different package managers. It would be > irrealistic to require devs to have a different installation just for > testing packages with paludis/pkgcore. Who's requiring devs to test anything? > So you are asking to go towards replacing portage with a package > manager that is not under gentoo control? Nowhere are we asking for anything to replace Portage as the primary Gentoo package manager. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 15:31:29 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > I know you would do that. My problem is not with how it is done. But > what is done. The problem is not about portage choking. The problem > is that at this point there is no reason to make paludis specific > changes to the tree. Changes are made to profiles all the time for the benefit of a package in the tree. How is this different? > Making package manager specific changes to the tree/profiles is even > more a dead end. This would mean that package managers are bound to a > profile (making it impossible to use the package manager properly). It would not be bound to a profile in any way. It can read and use any profile that Portage can. The new profile(s) would be purely for the convenience of those who want to use it and don't want Portage installed. > It would also mean that every package manager would have its own > profiles. A needless duplication that gets you nowhere. And how is this any different from having seperate subprofiles for NPTL or no-NPTL, for 2.4 or 2.6 kernels, or different compiler versions? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On Thu, 18 May 2006 15:34:28 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > Requiring duplication of profiles for every package manager. It requires duplicating nothing. This is exactly why we have cascading profiles. > Profiles determine what defaults are, and on some level what is > installed. What useflags are supported, and some other things. > > Profiles do not determine how something is installed. A package > manager determines how things are installed. As such any profile > should work with the package manager. And any profile does work with the package manager. What I want to change in the profile is exactly what is installed by default, which is as you say precisely what profiles are for. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 16:30:48 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > Paludis is not just a package, it is an alternative package manager. > The proposed changes are also not just the setting of a default for a > useflag. So? It's a package in the tree, and I'd like a new profile to make best use of it. Compare with the commercial/mysql profile if you like. The fact that its main purpose is to install software is irrelevant. > What you are requesting is adding a different version of > gentoo. Right, in the same way that the Alpha or hardened profiles are a different version of gentoo. > I already stated that I would find a no-portage profile discussable. > This profile would then mean that portage, pkg-core, and paludis > would be able to handle it. This I would see as a viable alternative in the short term. It should probably be moved into a different thread though, due to the sheer volume of noise in this one. > I am not sure though whether having a portage virtual would not be > enough. As portage depends on python, it would be worthwhile to > research whether removing python from the default package list works. > In that case it is possible to remove the explicit portage dependency > from the tree. Again, a step in the right direction, but should probably be in its own thread by now. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On Thu, 18 May 2006 16:37:00 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > Cascading profiles form a tree with N nodes. Some of these nodes are > abstract in the sense that they are not directly usable. Say that > leaves M possible profiles. To have paludis be on par with portage, > each of these M profiles would have a leaf added for paludis. The > same holds for pkgcore and for any other package manager. This would > mean that we have N+2M profiles. With a paludis and pkgcore toplevel > profile this would even be worse and amount to approximately 3N > profiles. > > In the leaf version, all M paludis specific profiles are equal. OK, a valid technical objection. The way to avoid this, as I see it, is to remove all direct references to Portage and its dependencies (Python?) from the system set, and replace them with the virtual. Then make sure that no package assumes that Python will be in system, and explicitly depends on it where necessary. At that point, a system could sanely be installed with any package manager by installing it before the rest of the system set. Long term this is possibly a better solution, but in the short term it requires an order of magnitude more effort, and has a significant effect on every profile in the tree. My original intention was to avoid having to change anything for other developers or people who still want to use Portage. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 16:50:59 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > This is not a reason. It is just repeating what I just said. Which > features does paludis have for its VDB format. And (per feature) why > can't this be done in a compatible way. We store more information than Portage in VDB, to remove the reliance that current Portage has on certain parts of the tree being immutable and in order to support multiple repositories properly (there is no longer a single place to look for, say, eclass data at uninstall time). We also construct VDB entries for old-style virtuals, which will confuse Portage. > What do you want then? Paludis does not aim to be compatible with > portage, so this disqualifies paludis as a secondary package manager. It aims to be compatible with the tree. As far as I know, it succeeds as things currently stand. > Two primary package managers is nonsensical. You ask for support in > the tree for paludis, meaning that you don't want to be unsupported > third party either. This leaves that you aim at paludis possibly > becomming a portage replacement. At present I ask not for support, but for a minor addition for convenience purposes. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On Thu, 18 May 2006 17:19:26 +0100 Edward Catmur <[EMAIL PROTECTED]> wrote: > But Paludis supports multiple inheritance. Would it be feasible to > have Paludis users create /etc/make.profile as a directory, > with /etc/make.profile/parent inheriting from both their chosen > gentoo-x86 profile and a profile in the paludis tree? Certainly possible, and even possible without doing anything ugly if we extend the inheritance to allow for paths specified relative to a named repository. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 21:35:01 +0200 Carsten Lohrke <[EMAIL PROTECTED]> wrote: > Sure baselayout is. An there're others in the tree, But that doesn't > mean these variants are supported (special cases like embedded aside). So they're unsupported alternatives to one of the core parts of gentoo, which have profiles for them in the tree. What's different? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 259 paludis-profile messages. ENOUGH!
On Thu, 18 May 2006 16:41:09 -0400 Peter <[EMAIL PROTECTED]> wrote: > So, while I am not endorsing pablum, at least let's cut the thread. I > see nothing useful coming from it anymore. While you may not see it, there are still useful points being raised. If you don't want to read it, don't. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Signing everything, for fun and for profit
On Fri, 19 May 2006 12:28:04 -0400 Peter <[EMAIL PROTECTED]> wrote: > Who signs the Manifests? The dev who commits it. > Why are some unsigned? Because some devs don't sign Manifests. > Is there a single > Gentoo Security Key (like I know Slackware has and some other distros > to ensure the authenticity of their files)? There's a releng key for the release media, but otherwise no, AFAIK. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements
I agree with the basic intent here, but remain unconvinced that this is the best way to solve the problems at hand. See below for comments on particular parts, and for what I believe could be a more elegant solution. It's not a complete proposal and will be rather rough around the edges, being more of a brain dump at the moment, but as far as I can see it addresses all the issues that need to be. On Sat, 20 May 2006 14:54:18 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > Backwards Compatibility > === > > Not a problem for this GLEP. There is no previous standard as the > issue did not exist before. This GLEP is to prevent future > compatibility issues. There's a strong argument for saying that converting Portage to fit the proposed standards for a primary package manager is a backwards compaibility consideration. Or, with my below suggestion, making sure that all existing ebuilds conform to the formalised ebuild specification. > The primary package manager is the package manager that sets the > standards for the tree. All ebuilds in the tree must function > with the primary package manager. As the primary package manager > sets the standard it does not have to maintain compatibility with > other package managers. The current 'Portage defines the tree format' is IMO a cause of a lot of problems at the moment. It would be better, I think, to define in a package-manager-agnostic document just what the current ebuild format (EAPI 0) means. If at any point in the future the primary package manager changes in what it supports and/or requires, a new EAPI spec is written. The council, or some other body, can then define which EAPI formats may be used by ebuilds in the tree. > The primary package manager is maintained on official gentoo > infrastructure, under control of gentoo developers. Reasoning behind this requirement? I can understand the sentiment, but if gentoo developers have a sufficient degree of control over the codebase, does it matter where it is hosted? If the worst comes to the worst, require that any supported package manager be licensed under GPL-2 and a group of Gentoo developers can simply pick up the latest version available and fork if it is required. > candidate primary package manager requirements > > > A candidate primary package manager aims to replace the > primary package manager. The council is responsible for deciding > whether this is done. The requirements are there to ensure that it > is actually possible to transition a candidate primary package > manager into the primary package manager. To throw out a potentially controversial question: is there any reason behind the implicit assumption that there can only be one fully supported primary package manager? If, as I suggested above, the ebuild format and environment is formally defined in such a manner, it should be entirely possible to support two or more alternative package managers. Currently this would be impractical at best because of the possibility of ebuilds working with one and not the other, but with a formal specification of the ebuild environment it becomes possible to define in such a case whether it is a package manager bug or whether the ebuild is making assumptions that are not valid according to the specification. > First of all, there must exist a transition path. This means that > the on disk data of the primary package manager can be used by (or > converted to a format usable by) the candidate primary package > manager. This requirement seems perfectly reasonable. > Second, there must be a test path. It must be possible for the > developers to test out the candidate primary package manager on > their working systems. This means that the transition path must > exist. This also means that there are no serious obstacles for > reverting to the current primary package manager. It strikes me that this, as well as the next requirement, can easily be achieved by chrooting, regardless of any compatibility or lack thereof between the two package managers. > Fourth, there must be support. This means that the package manager > is actively maintained under control of gentoo. If it is not > maintained on gentoo infrastructure, the means must be there to > move the package manager, with its change history, to gentoo > infrastructure. This means that it must be maintained on a gentoo > supported versioning system, or on a version system whose history > can be converted to a gentoo supported versioning system. Define "under control of gentoo". Also see above comment regarding Gentoo infrastructure. > A secondary package manager is a package manager that instead of > directly aiming at replacing portage as primary package manager. As > such a secondary package manager does not set the standard on the > tree, but follows the standard set by the primary package manager. Can't
Re: [gentoo-dev] GLEP 49 - take 2
On Mon, 22 May 2006 14:59:03 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > > "While it is desirable that the primary package manager be > > maintained on official gentoo infrastructure, under the control of > > gentoo developers, it is not required. During the path to becoming > > the primary package manager, the package manager maintainers must > > be asked if they would like their project to be an official Gentoo > > project. All rules about projects apply. The package manager > > maintainers have the right to refuse such an offer if there is a > > team of at least 3 Gentoo developers that understand the package > > manager source code and are willing to deal with bugs, testing, > > feature enhancements, modifications, and integration." > > First of all, I'm in limbo on this. Certainly not dead set against > it. If this were to be used, I'd like to add the following line: "At > least 1 of these three must be actively involved in the development > of the package manager". > > Could others please provide input on this question. So far this seems the most reasonable wording of that paragraph suggested, with or without your modification. I'm still unconvinced of the general approach taken by the GLEP (see my mail in the previous thread), but if the categorisation is to be made I'd like to see that paragraph replace the current. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 49 - take 2
On Mon, 22 May 2006 16:31:40 + [EMAIL PROTECTED] (Tim Yamin) wrote: > Maybe I'm reading it wrong but the above sounds like if there's less > than "3 Gentoo developers that understand... ... ..." the package > maintainers *don't* have the right to refuse and magically get sucked > into Gentoo whether they like it or not? If there cannot be found 3 Gentoo devs with the relevant knowledge and the developers decline to have it made a Gentoo project, we don't use it as a primary package manager. Seems fairly straightforward to me... -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Gentoo Devmanual
On Wed, 24 May 2006 18:36:07 -0400 Peter <[EMAIL PROTECTED]> wrote: > If you have any corrections, suggestions or improvements please > contact the editors. Large portions of the handbook were originally > written by Ciaran McCreesh along with our contributors. Sorry, but did you have a point here? If so then I'm not seeing it. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Gentoo Devmanual
On Thu, 25 May 2006 07:04:05 -0400 Peter <[EMAIL PROTECTED]> wrote: > But face it, ciaranm did contribute and he was aptly credited. "at a minimum such credit will appear where any other comparable authorship credit appears and in a manner at least as prominent as such other comparable authorship credit." Two names are credited on the front page. One is conspicuously absent, despite having done the vast majority of the original work. > However, Tim and Mark are currently maintaining the body of work and > are properly titled as editors. Tim and Mark are devs. ciaranm is not. What does being a dev have to do with anything? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for June
On Thu, 1 Jun 2006 21:44:39 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > I would like the council to discuss GLEP 49 as has been discussed on > the list some weeks ago. It is about the package manager requirements. Isn't it customary for issues raised on the list to be addressed before a GLEP is submitted to the council? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Glep 49 (g2boojum's version)
On Fri, 02 Jun 2006 16:17:06 + Ferris McCormick <[EMAIL PROTECTED]> wrote: > What about ebuilds which for > whatever reason are invalid (serious specification violation, for > example, to the extent that QA would reject them), but portage accepts > them anyway. Must the alternative accept them as well? Precedent says that a new (minor) Portage version can quite happily break such ebuilds, so I see no reason to say that any alternative should accept them. On a side note, this is part of the reason why we really need the ebuild/tree format properly defined somewhere. It would remove any worries about compatibility between ebuilds and package managers, as long as ebuilds conform to a given specification, and the package manager supports it. It also defines in a much better manner just what a broken ebuild is. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Glep 49 (g2boojum's version)
On Fri, 2 Jun 2006 19:48:39 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > The problem is actually that such a document is a living thing and it > must not only exist initially but be maintained continuously. Must it? I'd be more inclined to say that if it needs to change, a new specification should be created based on the current one, and EAPI bumped. Each individual document should remain more or less unchanged once it's finalised, barring minor bugfixes. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Profiles Part 2
Many things were discussed in the last round of this thread (Paludis and Profiles, in case anyone missed it), and many useful points raised. One of these, which seems to have been largely missed in amongst the other noise, forms the basis of this proposal. It is in some ways more and in some ways less intrusive than the previous proposal, and is also completely package-manager-agnostic. In short, I would like to suggest replacing sys-apps/portage atoms in the base and default-linux profiles with virtual/portage, and removing the python dependencies from them. For most users this would have an effective zero change, since the default provider for virtual/portage is sys-apps/portage, and the python dependency will be pulled in by Portage when calculating system deps. According to my understanding, this should also produce no change when building release media, due to both Portage and Python being in packages.build. The only change introduced by this is that it becomes possible to bootstrap a system with a different package manager simply by installing it before 'system'. There are a couple more changes needed to allow this -- namely that a few system packages have old dependencies on >=portage-2.0.49, but these can be resolved seperately. Any problems caused by packages depending implicitly upon Python will show up only on systems not using Portage, and can be easily fixed with the cooperation of package maintainers. I would like to think that this proposal addresses most of the concerns raised in the last thread -- it implies nothing about support for any other package manager, and introduces nothing that could cause problems for Portage users, while still allowing alternative package managers to use the tree without needing Portage installed. I am also aware that this falls roughly under what the Council was asked to discuss in its June meeting, but since that seems to have not happened, I'm bringing it up anyway, since I would like to get something done here. Comments? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Profiles Part 2
On Mon, 12 Jun 2006 23:09:38 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > If you can spot those issues and fix them w/out rush on package > mantainers, no problems at all. I was assuming that they would be treated more or less as minor QA issues are currently. > PS: there is a formal spec about ebuilds now? That's on my List. Needs a few different sets of people on board though. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] GLEP 42 (News) revisited
datory.
``Posted:``
Date of posting, in ``-mm-dd`` format (e.g. 2005-12-18) for
compatibility with GLEP 45 [#glep-45]_. Translations should use the date
of the original news item. Mandatory.
``Revision:``
Initially 1. Should be incremented every time a change is made to the news
item. Changes that require a re-read of the news item (i.e., most changes
that are not spelling or formatting related) should instead use a new news
item. Mandatory.
``News-Item-Format:``
Must be ``1.0``. Future revisions to the format may increment the minor
number for backwards-compatible changes, or the major number for major
changes.
The following headers are used for filtering:
``Display-If-Installed:``
A dependency atom (for example, (which may also include a red warning message)
The package manager does not need to know how to launch the user's choice of
news client. This is consistent with the way configuration file updates are
handled.
The package manager may use a timestamp check file to avoid having to process
news items unnecessarily.
The package manager must keep track of news items that have already been added
to the unread list to avoid repeatedly marking a deleted news item. This could
be handled via a ``news-${repoid}.skip`` file containing the IDs of news items
that have already been added to a ``news-${repoid}.unread`` file, but this
method is not required by this GLEP.
Users who really don't care about news items can use ``rsync_excludes`` to
filter out the ``metadata/news/`` directory.
News Item Clients
-
Once a news item is marked for reading, third party tools (or traditional core
Unix tools) can be used to display and view the news files.
When a news item is read, its name should be removed from the
``news-${repoid}.unread`` file. If a news client acts as an interactive reader
rather than a gateway, it should then add the name to a ``news-${repoid}.read``
file in the same directory with the same file format.
An ``eselect`` [#eselect]_ module shall be created as the 'suggested' display
tool; other display tools (for example, a news to email forwarder, which would
be ideal for users who sync on a ``cron``) are left as options for those who
desire them.
News Item Removal
-
News items can be removed (by removing the news file from the main tree) when
they are no longer relevant, if they are made obsolete by a future news item or
after a long period of time. This is the same as the method used for ``updates``
entries.
Integration with Existing Systems
=
It would be simple to convert these news items into the format used for news
items on the Gentoo website or posts for the ``gentoo-announce`` mailing list.
There is an existing automated tool [#forums-glsa]_ for posting GLSAs to the
forums. A similar tool can be used for these news items.
Backwards Compatibility
===
Backwards compatibility is not a concern here. Existing tools will simply ignore
the ``news/`` directory.
Reference Implementation
A reference implementation of the required package manager support can be found
in Paludis [#paludis]_, along with a reference newsreader implemented as an
eselect module [#eselect-news]_.
Credits
===
The idea behind notifying users of news updates via Portage comes from Stuart
Herbert [#stuart-blog]_.
Thanks to Lance Albertson, Stephen Bennett, Donnie Berkholz, Grant Goodyear,
Brian Harring, Marius Mauch, Dan Meltzer, Jason Stubbs, Paul de Vrieze and Alec
Warner for input. Some of the ideas presented here are theirs, others go
completely against their suggestions.
Example Files
=
`example-news-item.txt `_
An example news item.
References
==
.. [#bug-11359] Bugzilla Bug 11359
"[NEW FEATURE] pkg_postinst/pkg_preinst ewarn/einfo logging",
https://bugs.gentoo.org/show_bug.cgi?id=11359
.. [#docs-policy] Gentoo XML Guide, Daniel Robbins et al.,
http://www.gentoo.org/doc/en/xml-guide.xml
.. [#eselect] eselect modular framework for configuration and
administration utilities,
http://www.gentoo.org/proj/en/eselect/index.xml
.. [#forums-glsa] Forums user GLSA,
http://forums.gentoo.org/profile.php?mode=viewprofile&u=55648
.. [#forums-apache2] Forums thread "Gentoo Apache2 Config Change Idiocy",
http://forums.gentoo.org/viewtopic-t-384368.html
.. [#glep-22] GLEP 22: "New "keyword" system to incorporate various
userlands/kernels/archs", Grant Goodyear,
http://www.gentoo.org/proj/en/glep/glep-0022.html
.. [#glep-31] GLEP 31: "Character Sets for Portage Tree Items", Ciaran
McCreesh,
http://www.gentoo.org/proj/en/glep/glep-0031.html
.. [#glep-34] GLEP 34: "Per-Category metadata.xml Files", Ciaran McCreesh,
http://www.gentoo.org/proj/en/glep/glep-0034.html
.. [#glep-36] GLEP 36: &q
[gentoo-dev] Defining the Tree: a proto-GLEP.
Continuing in the series of issues raised during the previous package manager discussions, I'd like to continue by mentioning the tree format. At present, it isn't defined beyond "what the current portage supports", which is frankly a fairly silly way to do things. Following discussion in #gentoo-portage, I'd like to set out to change that. My current idea is to draw up a formal specification of what ebuilds are allowed to do, and what to assume about the environment in which they run, as well as defining the formats of everything under profiles/, metadata.xml files, and other auxiliary information in the tree. I would envision the first version of this document to more or less codify existing practise, perhaps excluding some dubious tricks that are known to break in some cases. Generally, it should be possible to make the tree conform to the first version of the specification by changes no more significant than currently have QA bugs filed for them. It seems fairly obvious that any effort of this kind could potentially have implications, albeit hopefully very minor, across more or less all aspects of the tree, and so I'd like to seek as wide a range of input as possible before going ahead with it. The QA and Portage teams, based on my enquiries in IRC, seem broadly in favour, and I would imagine that this could be very helpful to Gentoo/ALT as well, so I'd like opinions from others at this point. Would you support such an effort, whether passively or actively? Would you oppose it? If so, why? Final implementation of it would I assume require the Council's approval; while I won't ask at this stage for a formal discussion I'd appreciate the views of its members on whether such an initiative is likely to pass. Any input is gratefully received. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Defining the Tree: a proto-GLEP.
On Mon, 12 Jun 2006 19:04:39 -0400 Luis Francisco Araujo <[EMAIL PROTECTED]> wrote: > I like the idea. This would be some kind of portage-tree standard? This would be, in essence, a formal definition of the layout of the tree, and the format of and assumptions made by every file contained within it. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (News) revisited
On Mon, 12 Jun 2006 19:26:18 -0400 Alec Warner <[EMAIL PROTECTED]> wrote: > > * 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``). > > > > not done, and if we implemented it, would be a hack (although > compromisable in this scheme, would be essentially a fake portageq > command)anrRokydtysyyetntgsI > > > * 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``). > > same as above > > > > > * Portage must extend ``portageq has_version`` to support > > restrictions to a given repository ID. > > and again > > > > > * Portage must extend ``portageq`` to implement a command which > > returns whether or not the profile used for a given repository ID > > is exactly the given profile (e.g. ``portageq profile_used > > default-linux/sparc/sparc64/2004.3 gentoo-x86``). > > and again > > > > > These extensions are assumed during the following specification. > > > > I have no problem with basically writing up 'fake' portageq calls. > However often people tell me overlays are important, they don't serve > as multipile repos and don't have metadata/news, so they are excluded > in this specification (intentially?). Portage doesn't do multiple > repo's so any repo-related call will be a 'fake' one, that just > returns the expected data, unless someone has a better method (looks > at other portage devs). I was assuming that given Portage's current lack of multiple repository support it would simply look to existing settings for all of these. The name can be grabbed from profiles/repo_name which already exists; the path can just return $PORTDIR if the name matches and error if not; the repository restrictions for has_version can simply be ignored, and the profile can check /etc/make.profile. > I am not sure if I pointed this out before, but I feel that news > items should be of a pragmatic nature. IE they should be useful but > not frequent. It should not be overly difficult to post a news item > for a particular incident. If news items are constantly being shot > down due to "importance" or some other reason that lacks what I would > call a reasonable blocking reason ( ie bad grammar, clarity problems, > inaccuracies ) it will discourage developers from submitting them. > While I am against completely crap news items, I would rather see > more news items than very few. While I don't like to appeal to common sense, given the ability to filter displaying of items based on profile, package installed, etc, it should be fairly easy to avoid flooding people with irrelevant news items without raising the bar so high that it discourages people. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Profiles Part 2
On Tue, 13 Jun 2006 09:42:16 -0400 Chris Gianelloni <[EMAIL PROTECTED]> wrote: > Please postpone any such changes, if approved, until at least July, as > we will be doing a snapshot before then, and I would prefer not having > to spend our entire release cycle just fixing possible problems from > these changes. Sounds reasonable. These changes can easily wait until after the 2006.1 release as far as I'm concerned, though ideally I wouldn't want to delay them any longer than necessary without a good reason. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, 14 Jun 2006 20:01:04 +0200 Jakub Moc <[EMAIL PROTECTED]> wrote: > This new terminology plain sucks. If you are sticking games into > in metadata.xml, you are just confusing me and other people > who are assigning bugs. It's not new. If it confuses you, perhaps you should learn the terminology used in metadata before you try to assign bugs based upon it. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, 14 Jun 2006 20:21:42 +0200 Jakub Moc <[EMAIL PROTECTED]> wrote: > Sure... so, perhaps you have some suggestion how I can read assign > bugs otherwise than using the metadata.xml; perhaps I could learn to > read minds of the developers who dump irrelevant stuff into > metadata.xml and expect someone to know what they meant. It's not irrelevant; you're just not reading it properly. You might notice that metadata.xml contains tags other than , like, say, . In the example that sparked this, is games and the individual dev who maintains it. Simple enough, no? A herd has always been a group of packages for as long as I can recall, which is about two years now. It's nothing new at all. Packages in that herd can be maintained by a developer or a project, or by the group of herd maintainers if there are no specific arrangements. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, 14 Jun 2006 22:34:55 +0200 Jakub Moc <[EMAIL PROTECTED]> wrote: > Please, go through the tree and see at least so many metadata.xml > files as I have seen, before claiming something that simply doesn't > reflect current practice. There are many ebuilds with no > tag and only. Are you claiming that they are unmaintained? No; read the second paragraph. > To make it pretty clear and explicit - bugs gets assigned to > (if there's any in metadata.xml), and get CCed to > (if there's any in metadata.xml). If there's no , whoever > is in will get that bug assigned and can happily smack you > butt once they've find out you've dumped the package on them without > their knowledge... ...so packages marked with a herd and a maintainer have bugs against them assigned to the maintainer. Sure, it would be polite to at least talk to the relevant herd maintainers before adding a package, but that holds regardless of whether you put it in the herd or not. Either way the bugs will go to the specific maintainer, so herds having bugs assigned to them that they don't care about isn't really an argument. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, 14 Jun 2006 20:54:21 -0400 "Dan Meltzer" <[EMAIL PROTECTED]> wrote: > According to the devmanual [1] > "A herd is a collection of developers who maintain a collection of > related packages" > > are you sure you are using the correct term? He's right. The devmanual is not authoritative. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eclasses maintainers - raise your hands please
On Thu, 15 Jun 2006 12:26:01 +0200 Jakub Moc <[EMAIL PROTECTED]> wrote: > versionator.eclass - anyone to take over after ciaranm? I can most likely take care of this one. Should be low enough maintenance anyway since for the most part it Just Works. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (News) revisited
On Mon, 12 Jun 2006 23:19:10 +0100 Stephen Bennett <[EMAIL PROTECTED]> wrote: > Since GLEP 42's original author and sponsor has left the project, I've > taken it over, and would like to have another go at getting it > implemented. OK, since noone has raised any significant issues with this, I'd like to ask the Council to discuss it at the next opportunity. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo Council Reminder for August 7
> If you have something you'd wish for us to chat about, maybe even vote > on, let us know! Simply reply to this e-mail for the whole Gentoo dev > list to see. I would like to put forward the following suggestion for the Council's consideration: "While the current state of PMS is not perfect, it is a reasonably close approximation to existing and historical behaviour of EAPI 0. Given this, and that getting a perfect definition is not feasible on a timescale shorter than several years, it should be treated as a draft standard, and any deviations from it found in the gentoo tree or package managers should have a bug filed against either the deviator or PMS to resolve the differences. "On the differences between EAPI 0 and EAPI 1, a much smaller topic, it is complete and can stand as a full specification" Alternatively, what (specific) changes are required to PMS before such a statement can be made?
Re: [gentoo-dev] Monthly Gentoo Council Reminder for July
On 01 Jul 2006 07:34:49 Mike Frysinger <[EMAIL PROTECTED]> wrote: > If you have something you'd wish for us to chat about, maybe even > vote on, let us know ! Simply reply to this e-mail for the whole > Gentoo dev list to see. GLEP 42. Noone on the list raised any objections last time it was sent out, so I'd like to send it off to the Council, so to speak. -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Thu, 6 Jul 2006 20:56:31 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > Selective and partial backporting of patches that leads to the C++ > standard library code getting broken? Obviously not an issue. Noone uses C++ anyway. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
On Tue, 4 Jul 2006 15:04:38 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > some other peeps: > Kugelfang / Ramereth / Mr_Bones / spb / plasmaroo / Weeve / `Kumba / > jaervosz / KingTaco / Flameeyes / dostrow / dsd / kito / exg Thanks, accepted. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 06 Jul 2006 14:31:56 -0700 Joshua Jackson <[EMAIL PROTECTED]> wrote: > Or instead of throwing a hissy fit yourself about diego not agreeing > with you..I don't know you could go and show the way that you feel it > should be done and show the technical merit. He already has done. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 06 Jul 2006 17:09:22 -0500 "Jory A. Pratt" <[EMAIL PROTECTED]> wrote: > Leaving aside the incoherent ad-hominem attack, could you please point out where the bullshit is? If you were referring to my post, I suggest you re-read Ciaran's first mail to this thread. He outlined at least two possible alternatives, but everyone seems to have ignored this. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] USE_EXPAND_HIDDEN: why make.globals?
On Thu, 06 Jul 2006 16:27:39 -0700 Zac Medico <[EMAIL PROTECTED]> wrote: > But anyway, base/make.defaults makes sense for now. It is done. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] atom matching behavior
On Thu, 3 Aug 2006 07:07:35 +0200 Marius Mauch <[EMAIL PROTECTED]> wrote: > Opinions? Current behaviour is sub-optimal in many regards, but the tree relies upon it; amongst other examples, packages depending upon =autoconf-2.5* expect to get 2.59. If someone wants to 'fix' all of those, and any other cases that may appear, I'd be for the change. -- gentoo-dev@gentoo.org mailing list
