Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 22:37, Stephen Bennett wrote: 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? They are at least partly supported. Also they do not aim to replace baselayout as the main gentoo basic setup. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpOVdL5gYIsT.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 20:35, Carsten Lohrke wrote: On Thursday 18 May 2006 20:43, Roy Marples wrote: Yes, part of it. baselayout is another part - and yet it's possible to run Gentoo on other variants like initng, daemontools and no doubt others. Sure baselayout is. An there're others in the tree, But that doesn't mean these variants are supported (special cases like embedded aside). Why make a special case for embedded? Maybe you haven't noticed, but baselayout is a virtual - which does make things harder as the main forks (vserver and fbsd) sometimes break when we add new things and they haven't synced up yet. But that's OK as they're supported I guess. Or are you saying that spb, other devs and people outside of Gentoo who has submitted SoC applications about Paludis (or what that qaludis?) are just going to wack it into the tree and then say we're not going to support it? Of course not! If az, vapier and myself upped and left Gentoo, would you rip out baselayout in favour of something else as there's no-one to support it? -- Roy Marples [EMAIL PROTECTED] Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Friday 19 May 2006 08:25, Paul de Vrieze wrote: On Thursday 18 May 2006 22:37, Stephen Bennett wrote: 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? They are at least partly supported. Also they do not aim to replace baselayout as the main gentoo basic setup. As someone who's talked to initng devs since their project began and someone who has contribed code so that networking worked on init-ng with a Gentoo config I can assure you that their goal is to replace baselayout in Gentoo. OMFG - lets rip initng from the tree as it's going to replace my lovely baselayout/sarcasm -- Roy Marples [EMAIL PROTECTED] Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 22:43, Ciaran McCreesh wrote: | You say that there is no such a thing as a primary package manager, | but fail to state any reason (here or in other mails) as to why this | is true. Instead of arguing why my support is false you just say that | I am saying things that are not true. This is an unbased accusation. No, I am claiming that your entire idea of a primary package manager is based upon circular logic and is thus invalid. It's like trying to debate the existence of green happiness -- since the thing the words describe is meaningless, there's no logical argument to be had. Then point out the circular reasoning. If you think you can't convince me, do it to convince others. Neither of us will have the final say in this. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpJjZEC8nZFZ.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 22:15, Ciaran McCreesh 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). Sure, some of them are supported. By supported I mean all relevant packages in the tree install matching init scripts. That means officially supported, compared to such a package being maintained. Carsten pgpSIhWLAeOpc.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Friday 19 May 2006 09:33, Roy Marples wrote: Maybe you haven't noticed, but baselayout is a virtual - which does make things harder as the main forks (vserver and fbsd) sometimes break when we add new things and they haven't synced up yet. I have nothing against a virtual. I just don't think polluting the profile subtree with alternative package mananger stuff is good idea. But that's OK as they're supported I guess. Or are you saying that spb, other devs and people outside of Gentoo who has submitted SoC applications about Paludis (or what that qaludis?) are just going to wack it into the tree and then say we're not going to support it? Of course not! No, I'm saying it's not the Gentoo package manager. Work on it, make it a viable contender for replacing Portage, but as long it isn't, keep it in an overlay. Carsten pgpAKM1VE6DjN.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Friday 19 May 2006 14:54, Carsten Lohrke wrote: On Thursday 18 May 2006 22:15, Ciaran McCreesh 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). Sure, some of them are supported. By supported I mean all relevant packages in the tree install matching init scripts. That means officially supported, compared to such a package being maintained. I can show you bugs where existing packages have invalid init scripts that just don't work with any baselayout version in portage. You could argue that they shouldn't be in the tree - if so then our imap server is foo-bared as it uses courier-imap. I suggest you check out bug #98745 for a clear definition of support. I can also show you Gentoo scripts used by ifplugd and netplug with init-ng support in the tree right now. I guess that means that init-ng has some level of support right? -- Roy Marples [EMAIL PROTECTED] Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Friday 19 May 2006 16:17, Roy Marples wrote: I can show you bugs where existing packages have invalid init scripts that just don't work with any baselayout version in portage. You could argue that they shouldn't be in the tree - if so then our imap server is foo-bared as it uses courier-imap. I suggest you check out bug #98745 for a clear definition of support. Bugs exist and should be fixed, but this is by no means an argument. I can also show you Gentoo scripts used by ifplugd and netplug with init-ng support in the tree right now. I guess that means that init-ng has some level of support right? There will be always someone who goes ahead. Fact is that every dev who maintains a package installing an init script is expecteted to do so for baselayout, but is free to say no, when someone requests an initng one, as long as it isn't the Gentoo default. Carsten pgpJ1JcWmUR3g.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Friday 19 May 2006 15:52, Carsten Lohrke wrote: There will be always someone who goes ahead. Fact is that every dev who maintains a package installing an init script is expecteted to do so for baselayout, but is free to say no, when someone requests an initng one, as long as it isn't the Gentoo default. You heard it guys - rip the djb stuff out of portage until the devs write scripts for baselayout. They have scripts for daemontools, but apparently it's not the Gentoo default. Or should we make an exception like you did for embedded? -- Roy Marples [EMAIL PROTECTED] Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
First of all, keep up the work with Paludis. Personally I think having a second package manager is a very good thing. I do have some questions. Could someone of the Paludis crew please answer them? 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. 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) 3) If using an own binary format will there be an extracter for it that isn't part of Paludis? Why am i asking this? Well i've seen instances when an upgrade broke something, and that was a dep of portage. So my emerge couldn't revert back. So i just untarred the tarball and recompiled it. (might not be the cleanest way, but the only way i found in certain situations). 4) Will Paludis ever become a Gentoo Project? Thank you very much for the hard work! Jochen -- Defer no time, delays have dangerous ends Ne humanus crede Jochen Maes Gentoo Linux Gentoo Belgium http://sejo.be http://gentoo.be http://gentoo.org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
** Dumb mode ** forgot to paste the exact size of the profiles dir in my previous mail... woops :-) First of all, keep up the work with Paludis. Personally I think having a second package manager is a very good thing. I do have some questions. Could someone of the Paludis crew please answer them? 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 7.4 M So my question would you be able to do tests without changing the official tree by copying the profiles dir in an own overlay. 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) 3) If using an own binary format will there be an extracter for it that isn't part of Paludis? Why am i asking this? Well i've seen instances when an upgrade broke something, and that was a dep of portage. So my emerge couldn't revert back. So i just untarred the tarball and recompiled it. (might not be the cleanest way, but the only way i found in certain situations). 4) Will Paludis ever become a Gentoo Project? Thank you very much for the hard work! Jochen -- Defer no time, delays have dangerous ends Ne humanus crede Jochen Maes Gentoo Linux Gentoo Belgium http://sejo.be http://gentoo.be http://gentoo.org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 21:49, Ciaran McCreesh wrote:
On Wed, 17 May 2006 21:22:28 +0200 Paul de Vrieze [EMAIL PROTECTED]
wrote:
| On Wednesday 17 May 2006 20:44, Ciaran McCreesh wrote:
| Portage still relies upon being able to source ebuilds, even if
| their EAPI isn't supported.
|
| Currently, nothing except the ability to parse bash directly would
| make it otherwise. Against my advise, there are no restrictions upon
| the EAPI variable. As such EAPI can not reliably be determined
| without understanding (or being) bash.
Not exactly true. There's nothing to stop a package manager from
gracefully handling not even being able to source the ebuild. The way
Paludis handles this is to create fake version metadata for weird
ebuilds with EAPI set to UNKNOWN. It's not perfect, but it avoids any
overly crazy behaviour.
This is not the standard, nor what portage does. It is what portage should
do, but not what it does. It would have been far preferable if doing an
egrep on ^EAPI would just be enough, but this is not true. EAPI can be
defined even by EAPI=${PV} (I know it is silly, but allowed).
My concern is not what paludis does, but what portage does. This means
that technically paludis can not support all EAPI cases properly (except
bailing out when parsing fails).
Paul
--
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net
pgpSPa4851fBh.pgp
Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 23:30, Ciaran McCreesh wrote: On Wed, 17 May 2006 17:00:10 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: | Paludis does not conform to the Release Engineering guidelines. It | is *incapable* of producing a Gentoo release. The authors have | expressed their intentions to *never* perform any actions necessary | to work towards making Paludis capable of producing a Gentoo release. And what has producing a releng-style Gentoo release got to do with using Paludis as a package manager? That's like saying ZSH shouldn't be included in the tree until it can be used in place of bash. There is only one case in which paludis should be supported by the tree. This is when paludis works towards being usable as a portage replacement. If the paludis authors do not aim at replacing portage, I suggest them to start their own distribution or (fork / derived distro). When paludis aims to be a viable replacement for portage, it must follow the requirements that hold for such a replacement. This means that at some point it must be possible to replace portage by paludis in a compatible way for all uses, including release engineering. If alternative ways to achieve the same better are provided that is also ok. A release is something to achieve, not some means to achieve something else. If paludis never wants to replace portage, but wants to be a secondary package manager it should not accept ebuilds that portage does not. Otherwise it would put itself in the position of a primary package manager, while not being capable to do so. Also a secondary package manager must work with the portage package database (VDB) in such a way that portage can always be used on the system where paludis has been used. You mean the *gentoo-x86* tree, right? The only reason some people call it the 'Portage' tree is that there's not previously been a need to call it something else. The tree. Whose cvs incarnation has been called gentoo-x86 for historical reasons. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpRwSwH7BXqD.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 19:38, Thomas Cort wrote: Isn't discussing if paludis can build ISOs for a bunch of arches a level of indirection? This thread was originally about adding a profile. The profile doesn't affect anyone who doesn't use it, nor does it require any changes to existing ebuilds or profiles. It adds no work for developers who are not interested. The only additional work load would be to bug wranglers for users who file bugs, and this has already been discussed. Can we please get back on topic. Is there a valid technical reason against adding the profile? The profile is a step in the process of paludis becomming accepted. Besides a profile being unneeded at this point, it is also to early to provide this level of support to an alternative package maanger. If the profile is accepted at this point, it also means that gentoo has accepted paludis in some way. This is a bigger way than just having it in the tree. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgphcMRUdlnEX.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 23:30, Stephen Bennett wrote: 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/. Neither option. Making 4 subprofiles is even worse than one toplevel profile. The point is however that for a portage replacement there should not be any profile changes needed (Or do you think that when pkgcore comes about we should have current*3 profiles, just to support each package manager?) Requiring a specific profile change just for a package manager is bad design. Next to this technical argument, adding anything for paludis sends the wrong message: - It says paludis is usable in gentoo. Which it isn't. - It says that paludis will be at some point supported by gentoo. Which decision has not been made yet and can not be made yet as paludis is not ready yet. - It says that other changes to specifically accomodate paludis will be made at later points. - It says that paludis is currently useable. It however is not. An installed system can not be converted to or from paludis. Paludis is not tested nor testable (requires conversion abilities). Paludis does not provide compatibility with current portage, therefore disqualifying itself as candidate for portage replacement. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp9TRLdVYL4w.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 00:26, Stephen Bennett wrote: 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. I seriously disagree with this action. Such profiles have the same problems as a toplevel profile, and as such are just as problematic as a toplevel paludis profile. Since the profile does not actually add anything except making portage a virtual (which is independent of paludis, and a good idea in any case), there is also no use for doing so. 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. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpl1B6vmDN6S.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On 2006.05.16 16:15, Stephen Bennett wrote: 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 Hi all, Being new to this list and having read every post since just before this discussion started, I feel its time for a generic summing up. There are a number of interesting questions arising from the thread along the lines of 1) Should the Gentoo tree support alternative package managers at all? 2) Should the tree be changed to enable experimental support to be added for alternative package managers? 3) Do alternative package managers have to be (at least) backwards compatible with Portage? 4) Should Portage be replaced by one (or more) of the alternatives? I'm deliberately avoiding the use of any names because Portage is the incumbent package manager and the questions have only been raised by one alternative package manager *so far*. Question 1) and 2) can be answered in the same breath. If its decided that alternative package managers will be supported then any required changes to make that possible are inferred, if indeed, its not actually possible at the moment. 1) is really a political/policy question, not a software engineering question, so should be determined by the council. 3) The answer has to be, as a minimum, alternate package managers need to be able to build on what Portage has already installed. That is, be backwards compatible. There is no need for users to have an 'undo' feature short of a reinstall. Experimental packages are just that, if you really might not be able to take the consequences, don't experiment. That's no different than for any other package now. 4) This does not even arise until satisfactory answers have been obtained to 1) and 2) and any potential Portage replacement has undergone a period of testing. However, there has to be a a way of migrating the user base to any new package manager should Portage become depreciated. Again, just like any other package. When alternate package manager(s) are proved to safely (no worse than portage) do everything from install to maintenance, there may be an interim stage where users can choose to install using package manager 'A' or package manager 'B', knowing that they cannot switch without a reinstall. There is no package in the tree that is sacrosanct - not even Portage. Gentoo must evolve (all of it) or die. The process is all self evident, its the same process that's followed for every other package in the tree. You probably don't want my views but here they are anyway. 1) Yes - packages managers are just packages, like every other package. 2) Yes - in a generic way. No special concessions to any particular package manager. I know its not like that at the moment because Portage defined Gentoo. Looking into the distant future, we can expect Package Managers to be replaced like other packages. 3) I'm ambivalent - I'm a user not a dev. 4) Only time will tell. Regards, Roy Bamford (NeddySeagoon) -- 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] 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] Paludis and Profiles
Christian Birchinger wrote: I honestly think people are just bringing up the wildest things just to find another reason to say no. It Looks a bit like even good ideas and project have no chance when they come from the wrong people. Thank you, you just summed up what I have been thinking about this thread. It seems like people are really looking for whatever possible technical reasons they to be able to say no simply because they don't like certain members of the paludis team. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 16:02, Stephen Bennett wrote: 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? 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. What you are requesting is adding a different version of gentoo. A package manager should not mean a different version at all. Whether I install subversion with portage or with paludis should not make any difference in the installed result. 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. 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. 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. 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? Those profiles are not tied to the package manager. A package manager does not change anything to the installed system (except its own metadata). All these other profiles do. -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpkDfghztgNK.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 15:58, Stephen Bennett wrote: 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. 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. 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? If I am to be a responsible package manager I have to test my package before I commit it into the repository. At a point where paludis has a status different from totally unsupported, this includes testing it with paludis next to testing it with portage. Besides this, to make an informed decision about granting paludis some more than totally unsupported status it is necessary to first test paludis. I, and I think many other devs with me, am reluctant to create a whole new tree to test out paludis. I also do not want to copy my whole tree to test it. 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. What do you want then? Paludis does not aim to be compatible with portage, so this disqualifies paludis as a secondary package manager. 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. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpHo7Wkw4EHu.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 23:34, Christian Birchinger wrote: I think at the moment there's no plan to replace anything. There was a simple request to add a profile to make it easier for some people to develop something. We can talk about replacing anything later, when there are more intrusive requests like changing all ebuilds etc. What is then the purpose of paludis. Is its purpose to create a package manager for a new distro, and the paludis team would like to use gentoo as a testing ground? Or is the purpose of the paludis team to have paludis be an alternative to portage. In that case it should respect portage, and make efforts to follow the standard that portage sets. I honestly think people are just bringing up the wildest things just to find another reason to say no. It Looks a bit like even good ideas and project have no chance when they come from the wrong people. If I only wanted to say No, I would not have needed this many words. Many of what I said applies just as well for pkgcore as for paludis (or any other package manager). What I have done is stated: - Why paludis accomodations are too early at this moment - Why package managers should not have their own profiles - What categories of package managers can exist (candidate replacement, secondary, third-party) - That there can only one primary package manager - What requirements exist for a secondary package manager - What requirements exist for a candidate replacement package manager - How paludis developers could enhance paludis such that it could be considered as a candidate portage replacement. - That the decision to replace portage should be made explicitly and should not be forced upon the project by packages in the tree requiring the candidate replacement package manager - That accomodations for a package manager can only be made for candidate package manager or for a secondary package manager (that must encertain full portage compatibility). Let's give some examples of what candidate package managers and secondary package managers can do. One of the biggest issues for amd64 is the fact that packages can not be installed for particular architectures or in paralel. An alternative package manager could offer a way that while allowing each architecture to be installed separately, it merges the files into one package and maintains separate files that record which subpackage which file belongs to. This way portage can remove the package, see that it's there and even verify the contents. It only can not itself provide multi architecture installation. Another thing is reverse dependencies. This is missing from portage, but a feature that could well be implemented independent of the on-disk system. Aditional package formats could be supported. The only restriction is that these must not be used in the official tree. They can be used in overlays, or in case of rpm support just used to install rpm packages and achieve a bigger LSB support. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpX9U90o3R8Q.pgp Description: PGP signature
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] 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] Paludis and Profiles
On Thu, 18 May 2006 16:54:58 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: | What is then the purpose of paludis. Is its purpose to create a | package manager for a new distro, and the paludis team would like to | use gentoo as a testing ground? | | Or is the purpose of the paludis team to have paludis be an | alternative to portage. In that case it should respect portage, and | make efforts to follow the standard that portage sets. No single purpose. Approximate goals are usually as follows: * The QA tool part, which has already found a whole load of issues in the tree and has had them fixed. * An alternative to Portage. Paludis itself is distribution agnostic. It can be used on a Gentoo system or on a non-Gentoo system as the user prefers. Paludis does not attempt to emulate every last oddity of Portage. It does not attempt to be usable in parallel with Portage, since that would prevent any useful features from being added. It *does* attempt to work with all existing ebuilds. It *can* read Portage-generated VDB, although at this stage we're strongly encouraging people not to try that, because there will probably be a few bugs... | What I have done is stated: | - Why paludis accomodations are too early at this moment By the same argument, icc shouldn't be in the tree. | - Why package managers should not have their own profiles Yes, very nice in theory. Unfortunately, Portage requires a whole load of Portage stuff in its profile, so that's not an option. | - What categories of package managers can exist (candidate | replacement, secondary, third-party) This categorisation is a false trichotomy. There is no reason for it to exist, and it has no value. | - That there can only one primary package manager | - What requirements exist for a secondary package manager | - What requirements exist for a candidate replacement package manager Again, nonsense based upon some random arbitrary segregation you're attempting to make that has no real world relevance. | One of the biggest issues for amd64 is the fact that packages can not | be installed for particular architectures or in paralel. An | alternative package manager could offer a way that while allowing | each architecture to be installed separately, it merges the files | into one package and maintains separate files that record which | subpackage which file belongs to. This way portage can remove the | package, see that it's there and even verify the contents. It only | can not itself provide multi architecture installation. Can't be done without huge ebuild changes. And were we to do that, we'd just implement multi-abi properly. Which would be trivial with Paludis and impossible with Portage. | Another thing is reverse dependencies. This is missing from portage, | but a feature that could well be implemented independent of the | on-disk system. Yes, carry on looking at the small picture. It's really really interesting! -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 11:52:49 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: | This is not the standard, nor what portage does. Portage has a bug that causes it to die a horrible death if ebuilds are not source-compatible. We do not emulate this bug, because there is no useful reason to do so and because handling it properly is only another half dozen lines of code. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 12:03:23 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: | There is only one case in which paludis should be supported by the | tree. This is when paludis works towards being usable as a portage | replacement. If the paludis authors do not aim at replacing portage, | I suggest them to start their own distribution or (fork / derived | distro). Paludis can already be used as a Portage replacement, if one so desires. It's still kinda rough around the edges, of course. | When paludis aims to be a viable replacement for portage, it must | follow the requirements that hold for such a replacement. This means | that at some point it must be possible to replace portage by paludis | in a compatible way for all uses, including release engineering. If | alternative ways to achieve the same better are provided that is also | ok. A release is something to achieve, not some means to achieve | something else. No, a release is merely a means to the end of installing a system. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 12:15:07 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: | - It says paludis is usable in gentoo. Which it isn't. Why don't you try it? I think you might find that it is in fact rather usable. Much more so than some GCC releases and kernels that have their own profiles in the tree, anyway. | - It says that paludis is currently useable. It however is not. Sure it is. | An installed system can not be converted to or from paludis. It can be converted *to* Paludis. | Paludis is not tested nor testable (requires conversion abilities). Nonsense. | Paludis does not provide compatibility with current portage, therefore | disqualifying itself as candidate for portage replacement. By that argument, future Portage versions aren't compatible with current Portage, and so are not a candidate for Portage replacement. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- 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. It's a goal towards which we're working. Just as we expect that, for example, gcc 4 will someday replace gcc 3 on some archs. | 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. That's how things are done at present. | 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) It's not that Paludis doesn't write it correctly. It's that Paludis writes some extra information that Portage can't handle. | 3) If using an own binary format will there be an extracter for it | that isn't part of Paludis? Why am i asking this? Well i've seen | instances when an upgrade broke something, and that was a dep of | portage. So my emerge couldn't revert back. So i just untarred the | tarball and recompiled it. (might not be the cleanest way, but the | only way i found in certain situations). tar. | 4) Will Paludis ever become a Gentoo Project? Pretty unlikely, past events considered. Personally I kind of like having commit access to my own code... -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- 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. That removes valid dependencies. | 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. Anything merged by Paludis may have a VDB entry that will confuse Portage. This is necessary for two reasons. Firstly, we have some features that Portage doesn't. Secondly, the VDB entries generated by Portage under certain circumstances (symlink/dir merge mismatches) are incomplete and incorrect, and Portage's unmerge code will falsely remove and falsely leave behind garbage when this happens, and we see no reason to emulate this bug. | 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. Can you install Portage 2.0 and Portage 2.1 in parallel? | 4) Will Paludis ever become a Gentoo Project? | | Doubtful, barring some rather drastic changes in Gentoo and the way | its projects are handled. | | So you are asking to go towards replacing portage with a package | manager that is not under gentoo control? What about Portage is under Gentoo control? Were Portage under Gentoo control, it would have the features that Gentoo developers require by now. Like, say, :slot deps. Similarly, Gentoo has no problem with bash, despite it not being a Gentoo project... -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Ciaran McCreesh wrote: | 4) Will Paludis ever become a Gentoo Project? Pretty unlikely, past events considered. Personally I kind of like having commit access to my own code... I thought we (Gentoo) already had SVN repositories with non-Gentoo-dev committers? I'm pretty sure that was one of the main goals behind stuart's overlay.gentoo.org proposal. -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 11:44:40 -0500 Grant Goodyear [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | | 4) Will Paludis ever become a Gentoo Project? | | Pretty unlikely, past events considered. Personally I kind of like | having commit access to my own code... | | I thought we (Gentoo) already had SVN repositories with non-Gentoo-dev | committers? I'm pretty sure that was one of the main goals behind | stuart's overlay.gentoo.org proposal. Yes, but I'm a security risk, remember? Thus why gentoo-syntax is now more or less dead... -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thu, May 18, 2006 at 06:11:35PM +0100, Ciaran McCreesh wrote: Again, nonsense based upon some random arbitrary segregation you're attempting to make that has no real world relevance. Yes, carry on looking at the small picture. It's really really interesting! Please refrain from making such (and similar) comments on the gentoo-dev list. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgptu4UcQlTqj.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 18:19, Ciaran McCreesh wrote: By that argument, future Portage versions aren't compatible with current Portage, and so are not a candidate for Portage replacement. The primary package manager has different standards to adhere to as any other. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpxTrUP4A1IA.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 17:44, Stephen Bennett wrote: 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). Is there any reason that this extra information can not be added in such a way that portage will just silently ignore it. Which changes to portage would be required to make it ignore it (but silently remove it when a package is removed). We also construct VDB entries for old-style virtuals, which will confuse Portage. Is there no way in which portage could be made to ignore this. Or to not create these entries (as portage can work without them). Being compatible with portage can mean extending portage such that compatibility is easier. 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. One that has more disadvantages than advantages as already pointed out. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp3MqhGmG28j.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 18:26, Ciaran McCreesh wrote: 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. That removes valid dependencies. Just remove it from the paludis system set. Is it that hard? | 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. Anything merged by Paludis may have a VDB entry that will confuse Portage. This is necessary for two reasons. Firstly, we have some features that Portage doesn't. Secondly, the VDB entries generated by Portage under certain circumstances (symlink/dir merge mismatches) are incomplete and incorrect, and Portage's unmerge code will falsely remove and falsely leave behind garbage when this happens, and we see no reason to emulate this bug. Then do it correct in a way that portage can still live with it. Otherwise write a portage patch so that it can live with it. Can you install Portage 2.0 and Portage 2.1 in parallel? These are versions of the same official package manager. A different situation. | 4) Will Paludis ever become a Gentoo Project? | | Doubtful, barring some rather drastic changes in Gentoo and the way | its projects are handled. | | So you are asking to go towards replacing portage with a package | manager that is not under gentoo control? What about Portage is under Gentoo control? Were Portage under Gentoo control, it would have the features that Gentoo developers require by now. Like, say, :slot deps. Similarly, Gentoo has no problem with bash, despite it not being a Gentoo project... Bash is not the gentoo package manager. If the council decided to tomorrow, it could revert portage releases, freeze portage releases, lock access to portage etc. It is under gentoo control. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpBGBWoRHs9R.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 19:14:16 +0200 Wernfried Haas [EMAIL PROTECTED] wrote: | On Thu, May 18, 2006 at 06:11:35PM +0100, Ciaran McCreesh wrote: | Again, nonsense based upon some random arbitrary segregation you're | attempting to make that has no real world relevance. | | Yes, carry on looking at the small picture. It's really really | interesting! | | Please refrain from making such (and similar) comments on the | gentoo-dev list. What, pointing out that the entire argument is bogus? It's kinda like this: Bash is Gentoo's primary shell. ZSH cannot be included in the tree as the primary shell unless it can work with every bash shell script (including ebuilds) without any changes (including paths and environment variables) to anything. ZSH cannot be included in the tree as a secondary shell if it can be used to do anything that Bash can do, including generating the .bash_history file. ZSH cannot be included in the tree if it has any features that Bash does not. However, you are allowed to use ZSH to display a picture of an ASCII cow, because Bash doesn't do that at the moment. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 19:47:55 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: | On Thursday 18 May 2006 18:19, Ciaran McCreesh wrote: | By that argument, future Portage versions aren't compatible with | current Portage, and so are not a candidate for Portage replacement. | | The primary package manager has different standards to adhere to as | any other. There is no such thing as a primary package manager and using such a term only serves to distract from what could otherwise be productive discussion. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 19:55:34 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: | Is there any reason that this extra information can not be added in | such a way that portage will just silently ignore it. Portage's handling of unrecognised data is not sufficiently clever to allow this to be done in any reasonable manner. | We also construct VDB entries for old-style virtuals, which will | confuse Portage. | | Is there no way in which portage could be made to ignore this. There are ways, but they all involve adding in really nasty hacks that will just keep on getting messier and messier in the future. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Paul de Vrieze wrote: At present I ask not for support, but for a minor addition for convenience purposes. One that has more disadvantages than advantages as already pointed out. Many of your comments have been quite valuable, but I've noticed that your recent posts fail to distinguish between facts and your opinion. This last statement falls into that latter category, of course, since the relative weighting of advantages and disadvantages has been pretty subjective so far. Incidentally, in reading this thread it seems to me that a tendency to offer opinions (or predictions) as though they were facts has been a common theme. Please try to separate the two, whenever possible. Thanks, g2boojum signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 18:11, Ciaran McCreesh wrote: On Thu, 18 May 2006 16:54:58 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: | What is then the purpose of paludis. Is its purpose to create a | package manager for a new distro, and the paludis team would like to | use gentoo as a testing ground? | | Or is the purpose of the paludis team to have paludis be an | alternative to portage. In that case it should respect portage, and | make efforts to follow the standard that portage sets. No single purpose. Approximate goals are usually as follows: * The QA tool part, which has already found a whole load of issues in the tree and has had them fixed. No problem with that. * An alternative to Portage. Paludis itself is distribution agnostic. It can be used on a Gentoo system or on a non-Gentoo system as the user prefers. This would make it a third party packaging solution that happens to work to some extend with ebuilds. This would give paludis the big flexibility, not supported by gentoo option. This means that no paludis specific changes must be made to the tree. Paludis does not attempt to emulate every last oddity of Portage. It does not attempt to be usable in parallel with Portage, since that would prevent any useful features from being added. It *does* attempt to work with all existing ebuilds. It *can* read Portage-generated VDB, although at this stage we're strongly encouraging people not to try that, because there will probably be a few bugs... That makes it not suitable to be used in replacement primary packager or secondary packager roles. Leaving the third party role. Gentoo support would thus send the wrong signal. | What I have done is stated: | - Why paludis accomodations are too early at this moment By the same argument, icc shouldn't be in the tree. Even if that is true, icc has been in the tree since (12 Apr 2002) making it a historical mistake that should be avoided for the future. | - Why package managers should not have their own profiles Yes, very nice in theory. Unfortunately, Portage requires a whole load of Portage stuff in its profile, so that's not an option. Then submit patches to portage to make it profile agnostic. | - What categories of package managers can exist (candidate | replacement, secondary, third-party) This categorisation is a false trichotomy. There is no reason for it to exist, and it has no value. Why and why? | - That there can only one primary package manager | - What requirements exist for a secondary package manager | - What requirements exist for a candidate replacement package manager Again, nonsense based upon some random arbitrary segregation you're attempting to make that has no real world relevance. Baseless accusations that are not supported by any argumentation. As long as you don't provide arguments I'll assume that you are out of arguments and try to convince me by baffling me. | One of the biggest issues for amd64 is the fact that packages can not | be installed for particular architectures or in paralel. An | alternative package manager could offer a way that while allowing | each architecture to be installed separately, it merges the files | into one package and maintains separate files that record which | subpackage which file belongs to. This way portage can remove the | package, see that it's there and even verify the contents. It only | can not itself provide multi architecture installation. Can't be done without huge ebuild changes. And were we to do that, we'd just implement multi-abi properly. Which would be trivial with Paludis and impossible with Portage. I can easilly come up with a way to do it without portage changes. It causes some stuff to be compiled too often, but does not break things. I can even invent some way that it does not conflict with portage VDB's. Why don't you use your intelligence to find ways to do things that do not conflict with portage (or people). | Another thing is reverse dependencies. This is missing from portage, | but a feature that could well be implemented independent of the | on-disk system. Yes, carry on looking at the small picture. It's really really interesting! These are just examples. Another example of a secondary package manager would be one that would allow installation of rpm packages in a portage compatible way. I'm not hurt by you calling me names. It just shows that the accusations against you were right. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpfmUYDzqf12.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 11:44:40 -0500 Grant Goodyear [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: | 4) Will Paludis ever become a Gentoo Project? Pretty unlikely, past events considered. Personally I kind of like having commit access to my own code... I thought we (Gentoo) already had SVN repositories with non-Gentoo-dev committers? I'm pretty sure that was one of the main goals behind stuart's overlay.gentoo.org proposal. getting OT now (but what in this thread is really on topic?), but overlays.g.o shouldn't be for general software hosting a la sourceforge, just for extensions to the tree (so a profile would fit in there, but not the paludis code itself). Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 20:02, Ciaran McCreesh wrote: It's kinda like this: Stop making such odd and wrong comparisons. The package manager is part of what defines a distribution, choosing a shell is the users choice. If you want to make the package manager matter of choice, start your own distribution. Carsten pgpW6ZEHHVCId.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 20:02, Ciaran McCreesh wrote: On Thu, 18 May 2006 19:14:16 +0200 Wernfried Haas [EMAIL PROTECTED] Bash is Gentoo's primary shell. ZSH cannot be included in the tree as the primary shell unless it can work with every bash shell script (including ebuilds) without any changes (including paths and environment variables) to anything. ZSH cannot be included in the tree as a secondary shell if it can be used to do anything that Bash can do, including generating the .bash_history file. ZSH cannot be included in the tree if it has any features that Bash does not. You can't seriously mean that. I'm not even going to try to point out that this is a rediculous analogy as you will not get the point anyway. Also paludis can be accepted in three if it does things that portage does not do. Ebuilds in the tree that are not specific to paludis must continue to function with portage. Otherwise the official package manager would not be able to use the official tree. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpzkRoJa1Xct.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 20:03, Ciaran McCreesh wrote: On Thu, 18 May 2006 19:47:55 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: | On Thursday 18 May 2006 18:19, Ciaran McCreesh wrote: | By that argument, future Portage versions aren't compatible with | current Portage, and so are not a candidate for Portage replacement. | | The primary package manager has different standards to adhere to as | any other. There is no such thing as a primary package manager and using such a term only serves to distract from what could otherwise be productive discussion. Why so. Portage is the one and only (thus primary) package manager for the gentoo tree. It is by itself responsible for the database of installed packages. This responsibility can only be held by one package manager at the time as multiple databases would create conflicts and / or missing information. That means at a system there is a primary package manager. The productive discussion is distracted from by your attempts to hamper my argumentation by making unsupported accusations against my reasoning. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpeOs5zxHpUJ.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 20:18:24 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: | * An alternative to Portage. | | Paludis itself is distribution agnostic. It can be used on a Gentoo | system or on a non-Gentoo system as the user prefers. | | This would make it a third party packaging solution that happens to | work to some extend with ebuilds. No, it works with a large part of the tree without modification. I'm not going to say all, because there're no doubt ebuilds out there that won't work (just as there are some that won't work with Portage), but Paludis is quite happy installing system + X + KDE + Gnome + all the stuff I use. | This would give paludis the big | flexibility, not supported by gentoo option. This means that no | paludis specific changes must be made to the tree. Why? Changes are made to the tree to support other packages all the time. | Paludis does not attempt to emulate every last oddity of Portage. It | does not attempt to be usable in parallel with Portage, since that | would prevent any useful features from being added. It *does* | attempt to work with all existing ebuilds. It *can* read | Portage-generated VDB, although at this stage we're strongly | encouraging people not to try that, because there will probably be | a few bugs... | | That makes it not suitable to be used in replacement primary packager | or secondary packager roles. Leaving the third party role. Gentoo | support would thus send the wrong signal. Again, you're falling back on meaningless categorisations. There is no such thing as a primary or secondary package manager. | | What I have done is stated: | | - Why paludis accomodations are too early at this moment | | By the same argument, icc shouldn't be in the tree. | | Even if that is true, icc has been in the tree since (12 Apr 2002) | making it a historical mistake that should be avoided for the future. And ZSH? | | - Why package managers should not have their own profiles | | Yes, very nice in theory. Unfortunately, Portage requires a whole | load of Portage stuff in its profile, so that's not an option. | | Then submit patches to portage to make it profile agnostic. I'm sorry, but waiting three years isn't exactly ideal here... | | - What categories of package managers can exist (candidate | | replacement, secondary, third-party) | | This categorisation is a false trichotomy. There is no reason for | it to exist, and it has no value. | | Why and why? Ok, in simpler language: You are pulling this whole primary / secondary thing out of your ass. It has no more meaning than Package managers that have the letter 'o' in their name / Package managers that do not have the letter 'o' in their name. | | - That there can only one primary package manager | | - What requirements exist for a secondary package manager | | - What requirements exist for a candidate replacement package | | manager | | Again, nonsense based upon some random arbitrary segregation you're | attempting to make that has no real world relevance. | | Baseless accusations that are not supported by any argumentation. As | long as you don't provide arguments I'll assume that you are out of | arguments and try to convince me by baffling me. *You* are the one making baseless claims. There is no such thing as a primary package manager that is in any way more meaningful than a package manager that has the letter 'o' in its name. | I can easilly come up with a way to do it without portage changes. It | causes some stuff to be compiled too often, but does not break | things. I can even invent some way that it does not conflict with | portage VDB's. Why don't you use your intelligence to find ways to do | things that do not conflict with portage (or people). You can't come up with a reasonable, usable solution that doesn't require ebuild changes. Nor can you come up with a solution to the VDB issue that is not an ugly hack -- you don't even know what the requirements are. | | Another thing is reverse dependencies. This is missing from | | portage, but a feature that could well be implemented independent | | of the on-disk system. | | Yes, carry on looking at the small picture. It's really really | interesting! | | These are just examples. Another example of a secondary package | manager would be one that would allow installation of rpm packages in | a portage compatible way. I'm not hurt by you calling me names. It | just shows that the accusations against you were right. Again, you're falling back on this whole secondary package manager thing. It has no meaning! -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Grant Goodyear wrote: Incidentally, in reading this thread it seems to me that a tendency to offer opinions (or predictions) as though they were facts has been a common theme. Please try to separate the two, whenever possible. Just to clarify, I was not limiting that comment to pauldv. -g2boojum- signature.asc Description: OpenPGP digital signature
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] Paludis and Profiles
On Thu, 18 May 2006 22:39:20 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: | Except that by that definition, Paludis *is* a primary package | manager. | | It is capable of being a primary package manager. On gentoo it is not | the primary package manager as that requires a council decision. Such | a decision would amount to deprecating portage. No, it's a choice best left up to the users. Ignoring Paludis and pretending it doesn't exist won't make it go away. | | What he is driving it at is that either paludis is an alternative | | (yet on disk compatible) primary, or it's a secondary- you keep | | debating the compatibility angle, thus the logical conclussion is | | that it's a secondary. | | We're an alternative, not entirely on disc compatible primary. | | This means that you could choose to meet the requirements that I am | currently writing down in GLEP shape for package managers that desire | to replace portage as the primary package manager. Those requirements | can be met, but would limit the freedom choise of implementation of | the package manager. GLEPs are to *Enhance*, not to hold back. | Design choice. We chose not to continue with previous design | mistakes that exist only because of limitations in Portage's dep | resolver where we can do so without requiring ebuild changes. | | This is a valid design choise. It does however mean that paludis | perhaps can not meet the requirements for being a replacement for | portage as gentoo primary package manager. You could come up with a requirement saying that any replacement for Portage must have an 'o' in its name. Wouldn't make it a valid requirement. Fact is, Paludis can be used as and is being used as a primary package manager. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Ciaran McCreesh: And that's your argument? If you're just going to sink to accusing anyone who disagrees with you of trolling then please retire gracefully before you make an even bigger fool of yourself. That's indeed funny. /me wrote: That actually was a serious question. But you and your gang are good in avoiding answering questions that you are not comfortable with. Now you are doing it again. - Even funnier that you cc'd devrel. Ciaran McCreesh: I was hoping you could continue providing constructive input as you were earlier on in the thread That's what you are really after? I'm still waiting for you to answer my questions then. -- Christian Hartmann http://www.gentoo.org/~ian/ PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x2154E5EE692A4865 Key fingerprint = 4544 EC0C BAE4 216F 5981 7F95 2154 E5EE 692A 4865 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On 5/17/06, Christian Hartmann [EMAIL PROTECTED] wrote: With respect to the hey support omg! comments i say stick a big fat README about being an experimental profile or something like that and that's it. Usually bug reports require emerge --info so it'll be easy to flag invalid ones anyway. Well. Marking a bug invalid doesn't make the real problem go away... but the users. I'd say that's exactly the intention of INVALID. If I were to file, say, a bug in GCC at Gentoo's Bugzilla instead of GCC's, it would be marked INVALID. (Unless, of course, the bug is caused by Gentoo's patches.) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Matthijs van der Vleuten wrote: On 5/17/06, Christian Hartmann [EMAIL PROTECTED] wrote: With respect to the hey support omg! comments i say stick a big fat README about being an experimental profile or something like that and that's it. Usually bug reports require emerge --info so it'll be easy to flag invalid ones anyway. Well. Marking a bug invalid doesn't make the real problem go away... but the users. I'd say that's exactly the intention of INVALID. If I were to file, say, a bug in GCC at Gentoo's Bugzilla instead of GCC's, it would be marked INVALID. (Unless, of course, the bug is caused by Gentoo's patches.) Actually it should be marked UPSTREAM. But we're getting a bit offtopic here. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Paludis and Profiles
On Tue, May 16, 2006 at 10:16:32PM +0200, Wernfried Haas wrote: This is not only about adding a profile, but if paludis is officially supported by being in the tree and profiles, fixes for paludis get into the tree etc, this sounds like paludis is a Gentoo project and users will expect it to work and be supported. They will be allowed to ask questions about something not working with paludis on the forums, mailing lists, on irc etc without being off-topic. So far and with respect to other distributions (like e.g. Vida, Kororaa or whatever they were called) a rule of thumb was: A Gentoo system uses the official portage tree, was installed using the Gentoo installation guide using Gentoo stages, etc - and which was rather implicit - using portage as package manager. As far i understand it paludis differs from that in many ways. So before the package manager gets optional and we support something quite different we really should figure out what we consider a Gentoo installation. Does the lack of responses mean everyone agrees to my point? We really should figure that stuff out before we start integrating an externally written package manager we have no influence on whatsoever - otherwise it would just be fair to do everything any other Gentoo based distribution demands from us as well. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpX6kb98CQQ8.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 10:23, Wernfried Haas wrote: On Tue, May 16, 2006 at 10:16:32PM +0200, Wernfried Haas wrote: This is not only about adding a profile, but if paludis is officially supported by being in the tree and profiles, fixes for paludis get into the tree etc, this sounds like paludis is a Gentoo project and users will expect it to work and be supported. They will be allowed to ask questions about something not working with paludis on the forums, mailing lists, on irc etc without being off-topic. So far and with respect to other distributions (like e.g. Vida, Kororaa or whatever they were called) a rule of thumb was: A Gentoo system uses the official portage tree, was installed using the Gentoo installation guide using Gentoo stages, etc - and which was rather implicit - using portage as package manager. As far i understand it paludis differs from that in many ways. So before the package manager gets optional and we support something quite different we really should figure out what we consider a Gentoo installation. I see no difference between this and other external projects which have an impact on the tree, like say gcc. If a gentoo dev puts an alpha of gcc in and it's package masked and stuff, then I expect devs that put Paludis in the tree to provide a similar level of support. I will happily provide support for baselayout and what I put it in the tree, but I'll provide exactly the same level of support for Paludis as I do for Portage - nothing. Does the lack of responses mean everyone agrees to my point? We really should figure that stuff out before we start integrating an externally written package manager we have no influence on whatsoever - otherwise it would just be fair to do everything any other Gentoo based distribution demands from us as well. Tell you what, you figure out the internals of baselayout or we'll remove it from the tree. I think a few Gentoo dev's know Paludis internals enough to support it. -- Roy Marples [EMAIL PROTECTED] Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Tuesday 16 May 2006 23:47, Stephen Bennett wrote: 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. Everything in the tree, including profiles, must be maintained by a project. One project may maintain 50 profiles, but there must be an identifyable GROUP of people responsible for anything in the tree, including profiles. (This has been true for at least 3 years, and was one of the main factors behind the herds thing). The group point is because that makes unsupported stuff less likely in the case of someone leaving. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpKvxZtoFhzo.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 01:15, Danny van Dyk wrote: There are several reasons to handle it slightly different: a) Paludis is a new package manager, not a different kernel nor userland. b) We don't need additional packages that need to go into the tree and which aren't used by any other arch than bsd. c) We don't need to keyword any packages. d) Paludis _can_ use existing profiles. There is no problem with that, and we did this for quite some time already. Interesting part is the multiple inheritance of profiles and the different (in my eyes improved) handling of profile configuration. In my eyes, these warrant adding a toplevel profile directory. Your argumentation is unfortunately incomplete. Paludis is a package manager whose development and profiles can be tested largely outside the tree. While having a profile package for paludis might be inconvenient, the functionality is not different. The main point you fail to mention however is that paludis is as yet not complete. At some point in the stabilisation of paludis gentoo has to decide whether paludis will receive some level of official support. At that time tests involving in-tree profiles can be conducted. There are however a number of requirements I want to state that paludis should meet before I consider it a stable portage replacement: - Paludis must be able to handle a standard portage /var/db/pkg tree. This means that paludis can read it, and write it. Enabling mixing portage and paludis up to some degree. - Paludis must work with all current ebuilds, and support all features of portage. This includes recognition of EAPI, and no renaming of the variables used. - No part of the tree, except those that by nature are paludis specific, may require the usage of paludis instead of portage. This requirement can only be removed after a decision is made by the council to retire portage in favour of paludis. - It would be greatly beneficial if paludis would create and use .tbz2 packages, but this is not essential. Below I'll outline some of the consequences. - Paludis may enhance ebuilds by directing the build process into a more efficient behaviour. As long as the ebuild still functions properly on portage, this should not be an issue. Examples would be in-ebuild documentation of use variables, enhanced dependency handling. - Paludis enhanced packages (except paludis related ebuilds) should only be accepted into the tree when it is seen as a stable package manager. - Paludis may choose to handle different format package descriptions (.ebuild.2?). Those can not appear in the official tree though before paludis is recognised as primary package manager. - Overlays can be used for various ways to extend paludis. - The first requirement of reading /var/db/pkg can be interpreted twofold. Either paludis should support it natively (as one of the options), or it should be able to convert from and to the /var/db/pkg format. - It is allowed for out-of-tree package descriptions to require a different installed package database format. Things like paralel installation of 32bit and 64bit packages require this. As yet the tree should not offer this though. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpV2qvUqiUfw.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 02:42, Stephen Bennett wrote: paludis/packages: -*=sys-apps/portage-2.0.51.22 *sys-apps/paludis Is there any reason that portage and paludis can not live together. As this basically blocks any kind of migration or backwards compatibility I see this as a very serious roadblock to the acceptance of paludis as a supported (secondary) package manager. 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. With the contents of this profile I see no reason whatsoever to include it in the tree. Paludis itself could easilly maintain a blocker on portage. The rest is so boilerplate that it has no added benefit of having paludis use the normal profiles. 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. Paludis at this point is just a third party package manager, comparable to rpm, and should be treated as such. Paludis could become a secondary package manager (waranting limited tree changes) when it has proved stability and has taken away all limits that prevent it from replacing portage at some point. If paludis does not aim at replacing portage, including an easy upgrade path and long testing, I see no point in using any gentoo resources in its support. This includes the pointlessness of making profile changes. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpxHhG6YrLXW.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
Paul de Vrieze wrote: On Wednesday 17 May 2006 02:42, Stephen Bennett wrote: paludis/packages: -*=sys-apps/portage-2.0.51.22 *sys-apps/paludis Is there any reason that portage and paludis can not live together. As this basically blocks any kind of migration or backwards compatibility I see this as a very serious roadblock to the acceptance of paludis as a supported (secondary) package manager. This is not a block. -*=sys-apps/portage-2.0.51.22 means that the depedency on portage is no longer in the system class (base defines it as such). -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, May 17, 2006 at 11:42:14AM +0100, Roy Marples wrote: On Wednesday 17 May 2006 10:23, Wernfried Haas wrote: On Tue, May 16, 2006 at 10:16:32PM +0200, Wernfried Haas wrote: This is not only about adding a profile, but if paludis is officially supported by being in the tree and profiles, fixes for paludis get into the tree etc, this sounds like paludis is a Gentoo project and users will expect it to work and be supported. They will be allowed to ask questions about something not working with paludis on the forums, mailing lists, on irc etc without being off-topic. So far and with respect to other distributions (like e.g. Vida, Kororaa or whatever they were called) a rule of thumb was: A Gentoo system uses the official portage tree, was installed using the Gentoo installation guide using Gentoo stages, etc - and which was rather implicit - using portage as package manager. As far i understand it paludis differs from that in many ways. So before the package manager gets optional and we support something quite different we really should figure out what we consider a Gentoo installation. I see no difference between this and other external projects which have an impact on the tree, like say gcc. If a gentoo dev puts an alpha of gcc in and it's package masked and stuff, then I expect devs that put Paludis in the tree to provide a similar level of support. So you consider a system using paludis instead of portage still a generic Gentoo installation, which we as Gentoo support in all ways? We may have a different understanding of the term support - in my eyes that doesn't mean it's just not broken, but we also give users support, allow them to ask questions and don't mark bugreports with INVALID. This also includes forums, irc, lists, writing docs, etc. So far we've been moving stuff out of the Gentoo forums to Off the Wall if people were using fancy overlays of their Gentoo based distribution or systems built with non official stages - so what do we do with systems using another package manager than portage? Does the lack of responses mean everyone agrees to my point? We really should figure that stuff out before we start integrating an externally written package manager we have no influence on whatsoever - otherwise it would just be fair to do everything any other Gentoo based distribution demands from us as well. Tell you what, you figure out the internals of baselayout or we'll remove it from the tree. I think a few Gentoo dev's know Paludis internals enough to support it. So because a few developers know its internals we can and do support it (in all ways as stated above)? That's exactly the issue i want to have answered clearly, sorry if it was a misunderstanding before. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpKEQZDot80X.pgp Description: PGP signature
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, May 17, 2006 at 01:42:53AM +0100, Stephen Bennett wrote: 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. snip Well if people are scared about there could always be a profile dir with the name development devonly broke unsupported 3rdparty or whatever (I don't really care). But i guess no matter how obviously it is, someone will always object. I'd say everything outside default-linux is fine. If you use something outside default-linux, some documentation must have suggested it to you anyway. With a deprecated (or similar info) the warning sign is big enough. If someone ignores all warnings and breaks his system i honestly wouldn't care. I don't even think this is necessary, but maybe it'll make a few more people accept it. If we can't even add something this small and trivial for development, we're doomed and there will be no progress anymore but only poinless huge discussions. Christian -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 13:11, Stephen Bennett wrote: 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. Is there a problem about both of them being there? 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. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp1zN9GAe98K.pgp Description: PGP signature
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 Tue, 2006-05-16 at 22:47 +0100, Stephen Bennett wrote: 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. Well, hardened/* and selinux/* are controlled by the Hardened Project, the Embedded Project controls uclibc/* and embedded/*, and Release Engineering (basically) controls default-linux with the assistance of the architecture teams, which are a part of the Base Project. The base/* profile is generally a collaboration of the above teams. The default-bsd/* and default-darwin/* profiles are controlled by the Gentoo/*BSD and Gentoo/Mac OS X Projects, respectively. So while there's no rule set in stone that a project exists, it is a generally followed practice. 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. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 07:03:27 +0200 Christian Hartmann [EMAIL PROTECTED] wrote: | Please try to come up with something sliiightly more plausible than | that when you're trying to attack something based upon your personal | prejudices. Or is that really the best criticism you can find? | | Uh yeah. It's all just based on my personal prejudices. - Why did I | give paludis a try (on several VMs) then first? Remember when paludis | was segfaulting? Sure. You ran -svn (our release check procedures would have caught that before it hit a release anyway), found a bug, and it got fixed and a testcase was added to ensure that the same kind of issue didn't reoccur. Did you want a cookie or something? | That's how you want to understand it. It's easy to pervert the facts | if one just constantly writes the same FUD over and over again. But | this doesn't change anything. People will become tired to discuss the | profile changes. Then the profile will be added. - You win. - Hooray. | | It has always been that way. - Changes won't be made because they are | sensible. They will be made because people are sick off wasting their | time on discussions like that. - So am I. If you'd like far less time wasted on discussions, perhaps you and your co-offenders should try not posting huge numbers of emails that are free of technical objections. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 01:58:02 +0200 Carsten Lohrke [EMAIL PROTECTED] wrote: | I haven't had a look at Paludis (the name sucks as much as the name | eselect had, before it was named eselect, btw.) yet, so I don't have | an opinion on it Aah, and this sums up this entire thread. The name sucks. I haven't used it. It isn't pink enough. | - tarball management (fetching via users tool of choice be it from | the web or according to a file list from a named media (e.g. DVD or a | tape), mirror handling etc.) | - profile management (keeping the on disk representation apart from | the way the dependency resolver gets the information) | - package management (dependency resolver, ect.) | - package installer (install files or create binary packages, may the | target be .tbz2, .deb or .rpm) | | and implement them as independent tools, so we can easly exchange one | for the other, if there is a superior one, instead having to throw | everything away?! Nice idea in theory. In reality, Portage is a big incestuous mess and can't have that kind of change made to it, and defining such an interface between package manager parts would take considerably more time and code than just rewriting the whole thing. Having said that, you can swap around pretty much any component of Paludis, since it's proper modular code -- Kugelfang has a mostly working implementation of a CRAN repository, for example. | I don't think it would be beneficial in the long run, if the outcome | would be that Gentoo divides into groups using different package | managers. I strongly suspect that in the long run one package manager will stand out as by far the best solution. Whichever one this ends up being, it will be one of the modular rewrites that makes future changes quite a bit easier. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 12:04:33 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: | - Paludis must be able to handle a standard portage /var/db/pkg tree. | This means that paludis can read it, and write it. Enabling mixing | portage and paludis up to some degree. Paludis can read a Portage-generated VDB. Portage can't read a Paludis-generated VDB, because Paludis has more features. | - Paludis must work with all current ebuilds, Portage does not work with all current ebuilds. | and support all features of portage. That's insane. Why should we support Portage-style 'candy' spinners? | This includes recognition of EAPI Funnily enough, unlike Portage, Paludis has full EAPI handling. | and no renaming of the variables used. Why should Paludis emulate Portage internals that no-one uses? | - No part of the tree, except those that by nature are paludis | specific, may require the usage of paludis instead of portage. This | requirement can only be removed after a decision is made by the | council to retire portage in favour of paludis. Again, insane. EAPI allows ebuilds using things that developers have been after for years (you know, slot and use deps) to be in the tree in such a way that they appear masked to Portage. That's a large part of the point of EAPI. | - It would be greatly beneficial if paludis would create and use .tbz2 | packages, but this is not essential. Paludis will use its own binary format. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Tue, 2006-05-16 at 23:22 +0100, Stephen Bennett wrote: 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. This is the exact reason why I would disagree with having this profile in the tree. It *is* going to cause more work for bug-wranglers, no matter how many places you put warnings and notices. If the profile is *not* in the portage tree, people won't file bugs in our bugzilla. If the profile *is* in the portage tree, then users will file bugs in our bugzilla. Anything that we add to the tree, we are expected to provide a reasonable level of support for maintaining. If there is a bug in Paludis, since the package *is* in our tree, users can file bugs in our bugzilla. Now, you might mark them as INVALID (which is wrong, btw) or UPSTREAM (which is right), but *somebody* has to take the time to look at the bug, determine that it is a Paludis bug, then do the work to UPSTREAM it. Proper usage of UPSTREAM means actually *filing* a bug upstream, not just pushing it off on the user, though this isn't used nearly as much in practice as it should be. A profile is an even more problematic affair, as it has an even longer-standing assumption that they are 100% supported by Gentoo. Paludis supports multiple repositories correctly, right? So why is it a big deal to provide the profiles in their own overlay/repository? I haven't heard a good reason why the profiles need to be in the portage tree. I'm not saying I am against it being added so much as I haven't heard a single compelling reason for doing it, and quite a few compelling reasons why *not* to do it, mainly support-related. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
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 13:40:18 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: | 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. | | Is there a problem about both of them being there? Yes. Portage has a few zillion deps more than Paludis. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- 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: | On Wednesday 17 May 2006 02:42, Stephen Bennett wrote: | paludis/packages: | -*=sys-apps/portage-2.0.51.22 | *sys-apps/paludis | | Is there any reason that portage and paludis can not live together. Sure they can. That's not what that profile says. | With the contents of this profile I see no reason whatsoever to | include it in the tree. Paludis itself could easilly maintain a | blocker on portage. The rest is so boilerplate that it has no added | benefit of having paludis use the normal profiles. Again, that's not what that profile says. You need to read up on how the packages file works. Basically, lines starting with a - are removed from the existing set. | If paludis does not aim at replacing portage I'm sorry, but the term Portage replacement has been banned by the Gentoo thought police. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, 2006-05-17 at 01:42 +0100, Stephen Bennett wrote: paludis/packages: -*=sys-apps/portage-2.0.51.22 -*sys-apps/portage would be best -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Paludis and Profiles
On Tue, 16 May 2006 15:56:38 -0700 Brian Harring [EMAIL PROTECTED] wrote: | This whole thing seems a bit dumb; it's not that far off from someone | coming along with a non-compliant c compiler, and arguing that | they're still compliant, they just dropped the stupid stuff they | didn't like. And this is why your whole argument is nonsensical. C is a documented and fixed standard (or rather, several of them). | | Add binpkgs, and try it- you'll get some fun behaviour there. | | As we're not emulating Portage's binary package format, it's not an | issue at all. | | Doesn't matter *how* you bundle the ebuild data (cpio/tar/whatever), | the issue of reloading the env still will exist, the container for | the data doesn't matter. What's your point? | A lot of the ebuild handling (especially environment) is done in | C++. You're missing all kinds of things by only looking at the bash | code. | | And portage does a lot of crazy shit in python for env handling | also. Sooner or later however, it hands control over to bash with a | pregenerated environment for the ebuild to execute in- what I keep | pointing out (and you keep dodging) is that the ebuild env *must* be | consistant, regardless of the actual pkg manager implementation. And hey, we do provide a consistent environment. | You deviate from the standard of the tree, you break your support | for the tree. Pretty simple, users being the ones who see the mess. Ok, so the *tree* is the standard now, not Portage? That's good, because the tree is the standard we're using. | | Feel free to suggest them- since it's initial discussion, your | | comments on it haven't really progressed beyond y'all did it | | badly, without naming a solution that works. | | I gave you two that worked. One, the .ebuild.n thing, which avoids | the filename incompatibility issue and the source issue. Two, the | eapi as a function thing, which avoids the source issue. | | 1) sucks- folks aren't going to be happy when they have | mplayer-1.0.1.ebuild.25 Yes, but unfortunately it's the only way around Portage exploding horribly when it encounters something it doesn't understand. | 2) EAPI as a function is no different then EAPI as a var, just | massively slower since you have to shell out more. Untrue. If the eapi function checks that the eapi is supported and bails with an understandable error if not, the rest of the file doesn't have to be source compatible. | Which is a good thing. Rather than emulating one of Portage's | sillier misfeatures, which only came about because of the whole | single repository concept being hard-coded, we did it properly. | | So... let me see if I grok this- last response, state it supports | eclass unified overlays (blurb above). Now you're stating that it | doesn't, because it's one of portage's misfeatures. Please don't | waste the bandwidth doing that again. Try defining your terms properly. It supports overlays with a unified eclass directory. It doesn't support overlays with unified eclasses from different directories. | Stating it won't be a silent failure does not make it so- line 1023 | of portage.py directly contradicts that. There are other ways of making Portage fail non-silently, as you know fine well. | If your parent parsing implementation handled N parents on a single | line (rather then parent per line as you do now), portage would | explode rather then silently use the left most. Your implementation | isn't doing that however... Disallows spaces in paths. Which, admittedly, is probably a good thing. | | Bit retarded here, but seriously, work it out in the overlay | | (like most herds do), then try to bring it to the tree. | | Oh, we already went through that stage. | | So... where's the sample profile? :) Elsewhere in the thread. | | That and the thread is getting fairly wide in discusion, rather | | then the profile specific does alt pkg manager X cruft belong in | | the tree? | | Well yes, because rather than discussing the issues, you're trying | to turn this into your personal crusade against Paludis. | | Sorry you see it that way, meanwhile kindly address the points I've | been raising What points? When you start coming up with points relevant to a Paludis profile and stop using this as a personal vendetta I might be interested. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Chris Gianelloni wrote: On Tue, 2006-05-16 at 23:22 +0100, Stephen Bennett wrote: This is the exact reason why I would disagree with having this profile in the tree. It *is* going to cause more work for bug-wranglers, no matter how many places you put warnings and notices. If the profile is *not* in the portage tree, people won't file bugs in our bugzilla. If the profile *is* in the portage tree, then users will file bugs in our bugzilla. Anything that we add to the tree, we are expected to provide a reasonable level of support for maintaining. Last time I checked, we don't support *everything* in the tree, for example everything in package.mask and/or keyworded -* is considered unsupported (or are you trying to tell me that sys-devel/gcc-4.2.0_alpha20060513 is officially supported). If there is a bug in Paludis, since the package *is* in our tree, users can file bugs in our bugzilla. Now, you might mark them as INVALID (which is wrong, btw) or UPSTREAM (which is right), but *somebody* has to take the time to look at the bug, determine that it is a Paludis bug, then do the work to UPSTREAM it. Proper usage of UPSTREAM means actually *filing* a bug upstream, not just pushing it off on the user, though this isn't used nearly as much in practice as it should be. A profile is an even more problematic affair, as it has an even longer-standing assumption that they are 100% supported by Gentoo. Deprecated profiles are considered unsupported, as are most of the gentoo-alt profiles. Also most arches have development profiles which are considered unsupported (on amd64 we add a profile.bashrc that dies unless something like I_WANT_TO_BREAK_MY_SYSTEM=1 is set). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 15:50, Ciaran McCreesh wrote: On Wed, 17 May 2006 01:58:02 +0200 Carsten Lohrke [EMAIL PROTECTED] wrote: | I haven't had a look at Paludis (the name sucks as much as the name | eselect had, before it was named eselect, btw.) yet, so I don't have | an opinion on it Aah, and this sums up this entire thread. The name sucks. I haven't used it. It isn't pink enough. Please do not mix up the flaming between you and Diego with my email. Yes, it isn't pink enough and I don't like your ponytail either. :p Nice idea in theory. In reality, Portage is a big incestuous mess and can't have that kind of change made to it The former yes, the latter statement is questionable. , and defining such an interface between package manager parts would take considerably more time and code than just rewriting the whole thing. That won't mean you face the same situation at one point again, so you likely have to spent the same or even more amount of time, just over a longer time frame. Having said that, you can swap around pretty much any component of Paludis, since it's proper modular code -- Kugelfang has a mostly working implementation of a CRAN repository, for example. Doesn't sound like independent runtime components, as I am proposing. Carsten pgp2WslpBUQjv.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
Why risk anything by changing the tree to suit the package? It just seems like asking for trouble. The overlay ability is there for a reason. 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
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 09:58:41 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: | Paludis supports multiple repositories correctly, right? So why is | it a big deal to provide the profiles in their own | overlay/repository? I haven't heard a good reason why the profiles | need to be in the portage tree. I'm not saying I am against it being | added so much as I haven't heard a single compelling reason for doing | it, and quite a few compelling reasons why *not* to do it, mainly | support-related. We'd have to extend the parent file to support something like: $(location_of_repository_named gentoo)/profiles/default-linux/etc since a) profiles are per-repository and b) we don't want to copy the whole Gentoo profile structure. Now, whilst this change could be useful, it's going to cause a huge incompatibility with Portage... So unless someone can come up with a solution that won't... -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 16:17, Patrick McLean wrote: Deprecated profiles are considered unsupported, as are most of the gentoo-alt profiles default-bsd *is* supported. Gentoo/FreeBSD project (that would be myself) takes care of all the bugs related as fast as possible. The unsupported Gentoo/Alt profiles are in the Gentoo/Alt overlay. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpWkNQloXzYr.pgp Description: PGP signature
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, May 17, 2006 at 10:06:54AM -0400, Chris Gianelloni wrote: On Wed, 2006-05-17 at 01:42 +0100, Stephen Bennett wrote: paludis/packages: -*=sys-apps/portage-2.0.51.22 -*sys-apps/portage would be best Everything after the - must be *exactly* what is already specified in base/packages, or it will have no effect. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On 17/05/06, Stephen Bennett [EMAIL PROTECTED] wrote: On Wed, 17 May 2006 15:25:08 +0100George 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. Any adding is increasing the risk. 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 notthere to try to mix profiles between repositories. Surely then it would be better to work on a comprimise for the sake of Gentoo rather than paludis. Horse before the cart. 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 treeIt is, it is, it won't unless the user screws up (as with, say,Portage), and it is. 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.
Re: [gentoo-dev] Paludis and Profiles
On Wed, 2006-05-17 at 12:04 +0200, Paul de Vrieze wrote: - It would be greatly beneficial if paludis would create and use .tbz2 packages, but this is not essential. It *is* essential if paludis were to ever be used for release building. Otherwise, it isn't required. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 16:21:13 +0200 Carsten Lohrke [EMAIL PROTECTED] wrote: | Nice idea in theory. In reality, Portage is a big incestuous mess | and can't have that kind of change made to it | | The former yes, the latter statement is questionable. Not really. It's why everyone is busy rewriting Portage. The code simply isn't modular enough to make ripping out any particular component viable. | , and defining such an | interface between package manager parts would take considerably more | time and code than just rewriting the whole thing. | | That won't mean you face the same situation at one point again, so | you likely have to spent the same or even more amount of time, just | over a longer time frame. And no matter how many times people end up rewriting things, doing a generic future-proof cross-language interface that supports everything that *might* be done in the future is going to take so long that it will never actually get written. | Having said that, | you can swap around pretty much any component of Paludis, since it's | proper modular code -- Kugelfang has a mostly working | implementation of a CRAN repository, for example. | | Doesn't sound like independent runtime components, as I am proposing. It's compile time at present, simply because no-one considers it worth the effort of screwing around with .so files until it's really really necessary. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 10:06:54 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: | On Wed, 2006-05-17 at 01:42 +0100, Stephen Bennett wrote: | paludis/packages: | -*=sys-apps/portage-2.0.51.22 | | -*sys-apps/portage would be best Unless our code is wrong, that won't work. My understanding of what's supposed to happen is that -string removes dep atoms equal to that string. There's no fancy do these ranges intersect code, nor can I think of a way to reasonably define such a thing. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 10:57:55 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: | On Wed, 2006-05-17 at 12:04 +0200, Paul de Vrieze wrote: | - It would be greatly beneficial if paludis would create and | use .tbz2 packages, but this is not essential. | | It *is* essential if paludis were to ever be used for release | building. Otherwise, it isn't required. No, support for *some* kind of binary package format is necessary. Support for Portage .tbz2 packages is pointless. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 15:57, Ciaran McCreesh wrote: On Wed, 17 May 2006 12:04:33 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: | - Paludis must be able to handle a standard portage /var/db/pkg tree. | This means that paludis can read it, and write it. Enabling mixing | portage and paludis up to some degree. Paludis can read a Portage-generated VDB. Portage can't read a Paludis-generated VDB, because Paludis has more features. | - Paludis must work with all current ebuilds, Portage does not work with all current ebuilds. | and support all features of portage. That's insane. Why should we support Portage-style 'candy' spinners? Let me clarify my statement. I don't care about candy spinners. Paludis (or any other package manager that is to be integrated into gentoo) should basically be able to allow a level of mix and match. This means that at the initial import, it can be run on any package instead of portage, and the results still be usable for portage (possibly after a conversion stage). This allows testing out the package manager. | This includes recognition of EAPI Funnily enough, unlike Portage, Paludis has full EAPI handling. Great. And I agree that EAPI was not taken as far as it should within portage. | and no renaming of the variables used. Why should Paludis emulate Portage internals that no-one uses? If they are internals I don't care. If they are part of the API exposed to ebuilds then these variables should still be provided. If variables are not part of the public API, but still used regularly I consider them still part of the API. | - No part of the tree, except those that by nature are paludis | specific, may require the usage of paludis instead of portage. This | requirement can only be removed after a decision is made by the | council to retire portage in favour of paludis. Again, insane. EAPI allows ebuilds using things that developers have been after for years (you know, slot and use deps) to be in the tree in such a way that they appear masked to Portage. That's a large part of the point of EAPI. Let's make clear why I put this in. Basically I am of the opinion that until a decision is made to make (in this case) paludis the primary package manager, all official packages should work with portage. Package masked packages are not considered official. If this restriction is not applied, it would create the situation that a decision is forced upon the council by (paludis) having features available that the official primary package manager has not. Thus requiring the use of a secondary package manager for certain applications. This in fact makes that package manager primary. | - It would be greatly beneficial if paludis would create and use | .tbz2 packages, but this is not essential. Paludis will use its own binary format. I assume there are valid reasons. I agree that the binary support can be improved. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp85nOPIiW4n.pgp Description: PGP signature
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 Wednesday 17 May 2006 14:24, Stephen Bennett wrote: 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. So this would be an effort to prevent users to shoot themselves in the foot. 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. 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. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpfnJoulVhoQ.pgp Description: PGP signature
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. How would you know? | In any case I think that optimally a package manager does not require | its own profile. Perhaps you should look at how much Portage stuff there is in the profiles. The Portage-specific things are why Paludis needs its own profile. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- 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:11:04 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: | Let me clarify my statement. I don't care about candy spinners. | Paludis (or any other package manager that is to be integrated into | gentoo) should basically be able to allow a level of mix and match. | This means that at the initial import, it can be run on any package | instead of portage, and the results still be usable for portage | (possibly after a conversion stage). | | This allows testing out the package manager. Not realistic. It means that any new package manager can't do anything new. I'd also like to point out that you can't upgrade to a new Portage version, install some things, downgrade to an older Portage version and expect things to carry on working. | | and no renaming of the variables used. | | Why should Paludis emulate Portage internals that no-one uses? | | If they are internals I don't care. If they are part of the API | exposed to ebuilds then these variables should still be provided. If | variables are not part of the public API, but still used regularly I | consider them still part of the API. This, funnily enough, is what we're doing. We're supporting things that are actually used, and things that people might reasonably use. | | - No part of the tree, except those that by nature are paludis | | specific, may require the usage of paludis instead of portage. | | This requirement can only be removed after a decision is made by | | the council to retire portage in favour of paludis. | | Again, insane. EAPI allows ebuilds using things that developers have | been after for years (you know, slot and use deps) to be in the | tree in such a way that they appear masked to Portage. That's a | large part of the point of EAPI. | | Let's make clear why I put this in. Basically I am of the opinion | that until a decision is made to make (in this case) paludis the | primary package manager, all official packages should work with | portage. Package masked packages are not considered official. What of EAPI masked packages? The same situation will occur when newer Portage versions supporting newer EAPIs are released into p.mask or ~arch. Some packages will end up relying upon something that isn't the stable package manager. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 16:08, Stephen Bennett wrote: 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. 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. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp6ZKaboatPb.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 17:21, Ciaran McCreesh wrote: 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. How would you know? | In any case I think that optimally a package manager does not require | its own profile. Perhaps you should look at how much Portage stuff there is in the profiles. The Portage-specific things are why Paludis needs its own profile. I couldn't find anything in the default-linux/x86 profile. Could you perhaps point something out for me. I realise that there is a lot of *ebuild* specific stuff there. That has more to do with what an ebuild is than what portage does though. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgprkj5LHP2tt.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 17:30, Stephen Bennett wrote: 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. 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. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpuXHighfzxW.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 10:17:16 -0400 Patrick McLean [EMAIL PROTECTED] wrote: Last time I checked, we don't support *everything* in the tree, for example everything in package.mask and/or keyworded -* is considered unsupported (or are you trying to tell me that sys-devel/gcc-4.2.0_alpha20060513 is officially supported). Where gcc-4.2.0_alpha is concerned, the important thing is that while it is not supported at the moment, it _will_ be supported in the future. The same is not being said for paludis at the moment - the paludis people are not claiming paludis will become official; I think everyone would agree it's too early to be thinking about that now. Deprecated profiles are considered unsupported, The key point there is that they're deprecated - deprecated means will be removed. That means anyone using them should be aware they will be removed at some point. Again, that's not what Paludis is about (if it was, the paludis team wouldn't be asking to put stuff in the tree!). as are most of the gentoo-alt profiles. (see Flameeyes response) Also most arches have development profiles which are considered unsupported (on amd64 we add a profile.bashrc that dies unless something like I_WANT_TO_BREAK_MY_SYSTEM=1 is set). However these are development profiles for actual supported profiles - in other words the stuff in the development profiles is expected to become supported at some point (either by inclusion or rejection). Again, not the case with paludis as it is currently being proposed. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
Matthijs van der Vleuten [EMAIL PROTECTED] said: I'd say that's exactly the intention of INVALID. If I were to file, say, a bug in GCC at Gentoo's Bugzilla instead of GCC's, it would be marked INVALID. (Unless, of course, the bug is caused by Gentoo's patches.) No, I would get a testcase for the bug and file it upstream. The only bugs I've marked invalid are for the testing versions of GCC. But, this is entirely off topic. -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpyozy4RbMJI.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 17:26, Ciaran McCreesh wrote: On Wed, 17 May 2006 17:11:04 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: | Let me clarify my statement. I don't care about candy spinners. | Paludis (or any other package manager that is to be integrated into | gentoo) should basically be able to allow a level of mix and match. | This means that at the initial import, it can be run on any package | instead of portage, and the results still be usable for portage | (possibly after a conversion stage). | | This allows testing out the package manager. Not realistic. It means that any new package manager can't do anything new. I'd also like to point out that you can't upgrade to a new Portage version, install some things, downgrade to an older Portage version and expect things to carry on working. No, a package manager can have many features. However, until it is seen as a candidate for becomming the primary package manager (or when it can function fully as secondary package manager (not being the boss in the installation tree)), the official tree may not rely on those features. Otherwise we get to a situation where the official tree relies on an unofficial package manager. The difference between portage and paludis is that portage is the officially supported package manager. This support is limited to the newest versions, but it is still official. Until the decision is made to make paludis the official package manager it isn't. An unofficial package manager should not limit the usage of the official package manager. | If they are internals I don't care. If they are part of the API | exposed to ebuilds then these variables should still be provided. If | variables are not part of the public API, but still used regularly I | consider them still part of the API. This, funnily enough, is what we're doing. We're supporting things that are actually used, and things that people might reasonably use. That is fair enough. | Let's make clear why I put this in. Basically I am of the opinion | that until a decision is made to make (in this case) paludis the | primary package manager, all official packages should work with | portage. Package masked packages are not considered official. What of EAPI masked packages? Nah. If a package requires the use of a non-primary package manager, that package effectively forces the use of that package manager. If that non-primary package manager can not coexist with the official package manager, the package effectively blocks the usage of the primary package manager. By blocking the usage of the official package manager, the package becomes unofficial and has no place in the official tree. This is basically to protect the official package manager. This is not because I like portage that much, but to provide some kind of unified direction. I am afraid that allowing various competing package managers would cause a wildfire of incompatible elements in the tree. Therefore there must be one official package manager that the tree works with. The same situation will occur when newer Portage versions supporting newer EAPIs are released into p.mask or ~arch. Some packages will end up relying upon something that isn't the stable package manager. Portage is however the official package manager. This means that these packages do not hamper the position of the official package manager. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpruynfUvXUM.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
Not realistic. It means that any new package manager can't do anything new. I'd also like to point out that you can't upgrade to a new Portage version, install some things, downgrade to an older Portage version and expect things to carry on working. This, funnily enough, is what people consider being a fork. While you are at it, why don't you just fork the portage tree? By doing so you would have the freedom to do whatever you want to do without keeping gentoo busy reading your mails. -- Christian Hartmann http://www.gentoo.org/~ian/ PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x2154E5EE692A4865 Key fingerprint = 4544 EC0C BAE4 216F 5981 7F95 2154 E5EE 692A 4865 -- gentoo-dev@gentoo.org mailing list
