Re: [gentoo-dev] Paludis and Profiles
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. > And I am willing to be part of it. -- gentoo-dev@gentoo.org mailing list
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
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 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 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 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 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 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 -- 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 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 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
Perhaps, The problem here is that the paludis team appear to have a conflict of interests due to their previous and/or current association with Gentoo. I know they've mentioned personal grudges, so despite not knowing who these people are, I'm going to assume they have a history with Gentoo. However, were a new package manager (such as Conary) to request on the Gentoo Developer list that the tree be changed to make their package manager would work slightly better, I have no doubt that they would meet a similarly mixed resistance. Whilst there may not be an easily explained technical reason not to make the change, there is no compelling reason *to* make the change either. Most likely the response to this message will be that Paludis isn't the same as Conary, and that it could eventually take over from portage. However, other portage replacements (such as pkgcore and the seemingly forgotten portage-C) have not required changes to the tree. No promises were made to the Paludis team concerning changes to the tree (as far as I'm aware), and I don't see how any external package management system could build their software *assuming* that they could eventually influence a distribution's package library. I am perfectly happy for Paludis to innovate in whatever manner it deems necessary, just as I am for Conary to develop, but (at the moment) as external entities to Gentoo. Hopefully the council meeting will clear all of this up, and I look forward to reading their decision... Mike 5:) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
I've read every mail thus far (even the mails sent from next month ). There is no technical reason that the profile shouldn't go in. Past precedent is set, most of the kinks regarding the profile have been worked out, yet members of the community are dead set against the idea. I think I was dead set against it too, a few weeks ago. However, everyone has the silliest of reasons, or so it seems. Everyone is afraid of switching, fear is good, fear keeps one cautious. However fear is also stifling, stifling innovation in this instance. Paludis is a way forward, as is any portage rewrite. It has bugs yes, it works for the most part yes. So why not give it a fair shot? Fear the Slipperly slope: First a new profile, then an eclass, then the tree! Paludis will take control of everything! Only if you let it. And to an extent, why not let it. Who has to commit all that crap that uses all the new shiny features? Thats right, developers do. If thats the way developers wish to go, than thats the way Gentoo may go. Of course, you need to keep standards in the tree, EAPI helps this a bit. Use something new in Paludis, EAPI it. Portage will gladly mask it properly. This is where the problem lies however. None of the paludis folk are asking for ebuild changes at this time. I say give them their profile; tell them if they make any ebuild changes you will cut their nuts off. Take it to the council and figure out a plan for migration, since there is more than one alternative coming up. We may need a plan similar to the CVS migration where someone goes off and does some testing and figures out what is best for Gentoo. The problem being with multiple implementations of something we have no standard for...they all need to match ;) Otherwise paludis will end up being...well..a fork. -Alec Warner -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thu, May 18, 2006 at 09:58:02PM +0100, Ciaran McCreesh wrote: > On Thu, 18 May 2006 22:39:20 +0200 Paul de Vrieze <[EMAIL PROTECTED]> > | > | 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. Several of your gleps restrict the tree (rhetoric not withstanding)- this is fundamentally no different, it's a restriction on what the is required of a pkg manager for it to be a primary available in the tree- this includes whatever profiles/mods it requires/wants. > | > 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. No one is disputing that. What they are disputing is whether paludis has any place in the tree if it's not going to be ondisk (whether profile, ebuild, or vdb) compatible with portage. Say paludis *did* get into the tree, and the changes you've coded into paludis already took hold- we would have a tree that is part paludis, and part portage. If it's not going to be compatible under guidelines council/approved glep dictates, then it has no place in the tree. Aside from that, lay off the smart ass "any replacement for portage must have an 'o' in its name" crap- folks aren't going to budge on this one, so just address the points they're raising rather then dodging it (thus requiring another email from 'em dragging the answer out of you). ~harring pgpVUA6u3WwBh.pgp Description: PGP signature
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=get&search=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 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
On Thu, 18 May 2006 22:27:59 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: | > Circular argument. | | Let me repeat it in primary school language. | | A supported statement is one which has the form: | | ... ... | | In short a supported statement has reasons that aim to argue why the | statement is true. And your definition of a primary package manager is: | 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. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 22:24, Ciaran McCreesh wrote: > | > | +1 troll > > 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. I was hoping you could > continue providing constructive input as you were earlier on in the > thread, although it looks like you've nothing useful left to say and are > resorting to petty flaming. This was a private mail, that by choise of Ciaran was posted to this list. -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpWABkFSIJE3.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 22:19, Ciaran McCreesh wrote: > On Thu, 18 May 2006 12:41:47 -0700 Brian Harring <[EMAIL PROTECTED]> > > wrote: > | Please talk to the OSX folk- they would disagree, since > | collision-protect was added to keep gentoo-osx from stomping on the > | primary installation (iow, to keep the secondary from acting like it > | was primary). Since you also spent a lot of time 'contributing' to > | prefix, I'd expect you'd understand the primary vs secondary role > | also (same with since you've ranted at autopackage). > > 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. > > | 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. > 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. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpgJu2a0VttS.pgp Description: PGP 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 Thursday 18 May 2006 20:42, Ciaran McCreesh wrote: > On Thu, 18 May 2006 20:33:05 +0200 Paul de Vrieze <[EMAIL PROTECTED]> > > wrote: > | > 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. > > Circular argument. Let me repeat it in primary school language. A supported statement is one which has the form: ... ... In short a supported statement has reasons that aim to argue why the statement is true. 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. This last email is close to slander. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpzErBcNMzGS.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 22:19:16 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: | On Thursday 18 May 2006 20:33, Ciaran McCreesh wrote: | > *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". | | +1 troll 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. I was hoping you could continue providing constructive input as you were earlier on in the thread, although it looks like you've nothing useful left to say and are resorting to petty flaming. -- 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:34:14 -0700 Josh Saddler <[EMAIL PROTECTED]> wrote: | Ciaran McCreesh wrote: | > The desired end result is installing a system. Paludis can do that | > already, if you really want, and it will be able to do it much more | > elegantly in the future. | | Aren't we looking (or trying to look) a *little beyond* just an | installed system? Oh, sure, it can do ongoing maintenance (upgrading, reinstalling, installing new things etc) too. But that point isn't contentious. -- 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:41:47 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: | Please talk to the OSX folk- they would disagree, since | collision-protect was added to keep gentoo-osx from stomping on the | primary installation (iow, to keep the secondary from acting like it | was primary). Since you also spent a lot of time 'contributing' to | prefix, I'd expect you'd understand the primary vs secondary role | also (same with since you've ranted at autopackage). Except that by that definition, Paludis *is* a primary package manager. | 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. | Re: vdb, the virtuals hack you've slipped in is paludis choice- you | design your manager properly, the vdb backend can be swapped out. In | other words, collect virtuals on the fly (ala portage/preexisting vdb | compatible), or convert that backend to a format that has the | virtuals flattened. | | Bluntly, if I can do it in pkgcore, you ought to be able to do it in | paludis. 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. -- 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 21:35:01 +0200 Carsten Lohrke <[EMAIL PROTECTED]> 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). Sure, some of them are supported. -- 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 07:33:27PM +0100, Ciaran McCreesh wrote: > 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. > 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". > *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". > Please talk to the OSX folk- they would disagree, since collision-protect was added to keep gentoo-osx from stomping on the primary installation (iow, to keep the secondary from acting like it was primary). Since you also spent a lot of time 'contributing' to prefix, I'd expect you'd understand the primary vs secondary role also (same with since you've ranted at autopackage). 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. > | 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. Re: vdb, the virtuals hack you've slipped in is paludis choice- you design your manager properly, the vdb backend can be swapped out. In other words, collect virtuals on the fly (ala portage/preexisting vdb compatible), or convert that backend to a format that has the virtuals flattened. Bluntly, if I can do it in pkgcore, you ought to be able to do it in paludis. It's just a matter of designing your repositories properly, you went for on disk virtuals to be faster at the cost of compatibility. Same for copying eclasses in, instead of doing env reinstating (you already keep a copy of the env), you went for "well, we'll fix it by copying the eclass in"- went for the quick route rather then the proper solution (again, if I can do it sanely in pkgcore, no reason you can't). Without clarifying the actual contents level difference (beyond collapsing fif/dev into misc), aka the "we can't convert because of symlink/dir issues", hard to comment on it- without an example, inclined to think it's not a vdb backend difference, just an unmerge strategy difference. ~harring pgpsgW1OQhqHQ.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: > The desired end result is installing a system. Paludis can do that > already, if you really want, and it will be able to do it much more > elegantly in the future. Aren't we looking (or trying to look) a *little beyond* just an installed system? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEbMw2rsJQqN81j74RAowoAJwK5QoMAchi/EsDrSMsofM9dI93qwCgsWfu v1f5qITTOuyHhEk6El3Yb4Q= =yucm -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
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). > Or are you saying that SUSE is RedHat as they use RPM? Can you install SUSE and RedHat packages arbitrary mixed!? No, you can't (well, you can, but...). Carsten pgp8mCizacJLU.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thu, May 18, 2006 at 08:04:36PM +0100, Ciaran McCreesh wrote: > On Thu, 18 May 2006 11:51:16 -0700 Brian Harring <[EMAIL PROTECTED]> > wrote: > | On Thu, May 18, 2006 at 07:34:16PM +0100, Ciaran McCreesh wrote: > | > On Thu, 18 May 2006 20:20:29 +0200 Carsten Lohrke <[EMAIL PROTECTED]> > | > wrote: > | > | 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. > | > > | > How many package managers does Debian have? What about Fedora? > | > | They all support the exact same format. > | > | You're changing the format, dropping what you dislike- they also > | support the same installed pkgs backend last I looked, again, not the > | case for paludis. > > No, they have a common subset of shared operations, just as Paludis and > Portage do. They have a common subset of shared *high level* operations, resolution differing dependant on the high level component used. Note I said 'high level', not low level, ie the format (which is what my point was). This is why despite most distro level bastardizations of the rpm spec, things still work- they're relying on a common tool/lib to handle low level details, rather then reimplementing them (and changing them) as paludis does. Simply put, others have a seperation between high level functionality (resolution, fetching, etc), and the low level format- high level differs elsewhere (leading to some fun issues like apt-rpm's inability to install N versions of a pkg), but the format bits are still common to that distro (rather then reimplemented by each). So no... not a valid counterarg- paludis relationship to portage (namely, we're going to do what we think is best format level despite what portage does) directly contradicts your arguement. ~harring pgpZbQ2PHpx04.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 11:51:16 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: | On Thu, May 18, 2006 at 07:34:16PM +0100, Ciaran McCreesh wrote: | > On Thu, 18 May 2006 20:20:29 +0200 Carsten Lohrke <[EMAIL PROTECTED]> | > wrote: | > | 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. | > | > How many package managers does Debian have? What about Fedora? | | They all support the exact same format. | | You're changing the format, dropping what you dislike- they also | support the same installed pkgs backend last I looked, again, not the | case for paludis. No, they have a common subset of shared operations, just as Paludis and Portage do. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Carsten Lohrke wrote: > 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. Just because it has historically been the case that a package manager often defines a distribution, that hardly means that it must do so. (Incidentally, I think that apt-with-rpm probably broke that perception long ago.) In any event, the ultimate issue, as far as I can tell, is whether or not it makes sense to have a package manager that would need to be chosen at the point of installation, but that would use the existing tree of ebuilds just as portage does. Would that be a Gentoo system? Personally, I don't see why it wouldn't, as it doesn't seem that different from deciding at install time to choose a BSD kernel and userland. Some modifications are required to use the system successfully compared to a default Gentoo Linux installation, but the overall philosophy remains the same. Now, would it be vastly more convenient if one could switch between portage and a portage alternative with no more hassle than running some sort of "conversion" scripts? Of course, and I suspect that somebody would write such scripts even if the lead devs didn't do it themselves, but I'm not sure that the bar for acceptance needs to be that high. -g2boojum- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thu, May 18, 2006 at 07:34:16PM +0100, Ciaran McCreesh wrote: > On Thu, 18 May 2006 20:20:29 +0200 Carsten Lohrke <[EMAIL PROTECTED]> > wrote: > | 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. > > How many package managers does Debian have? What about Fedora? They all support the exact same format. You're changing the format, dropping what you dislike- they also support the same installed pkgs backend last I looked, again, not the case for paludis. Better example please, because they're doing what paludis *should* be doing. ~harring pgpFihGzUW5L6.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 19:20, Carsten Lohrke wrote: > 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. 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. I believe that embedded doesn't use baselayout as such because we rely on bash and they rely on busybox. But last time I checked it was still Gentoo. Or are you saying that SUSE is RedHat as they use RPM? -- Roy Marples <[EMAIL PROTECTED]> Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 20:33:05 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: | > 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. Circular argument. -- 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 20:20:29 +0200 Carsten Lohrke <[EMAIL PROTECTED]> wrote: | 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. How many package managers does Debian have? What about Fedora? -- 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 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
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 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: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 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 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
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 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
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: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 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 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: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 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 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
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 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
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 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 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 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 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 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: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 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 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 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
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 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
On Thu, 18 May 2006 15:26:06 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > Then copy the bloody profile, or temporarilly add some magic in > paludis that ignores portage and python deps. Not that hard to do. > While not so beautiful it can easilly be removed at a later stage. And if something really does require python? > How far does that spread? Is this only for packages merged by > paludis, or does it spread? And what reasons are there for paludis > not to have a vdb format that will not confuse portage. A VDB entry created by Paludis can't be read by Portage. A VDB entry created by Portage can. > It is very important that package managers coexist with portage. This > allows testing of that package manager, but also the testing of a > package / eclass on different package managers. It would be > irrealistic to require devs to have a different installation just for > testing packages with paludis/pkgcore. Who's requiring devs to test anything? > So you are asking to go towards replacing portage with a package > manager that is not under gentoo control? Nowhere are we asking for anything to replace Portage as the primary Gentoo package manager. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 14:14, Stephen Bennett wrote: > 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. 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. 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 also mean that every package manager would have its own profiles. A needless duplication that gets you nowhere. And these are only the technical points. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgppq3OWrcNzV.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Thursday 18 May 2006 14:11, Stephen Bennett wrote: > 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. 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. > > > 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. 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. 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. > > 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. So you are asking to go towards replacing portage with a package manager that is not under gentoo control? Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgphzP82vJk1M.pgp Description: PGP signature
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 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 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 Thursday 18 May 2006 01:23, Ryan Phillips wrote: > Mike Auty <[EMAIL PROTECTED]> said: > > Forgive me, > > I'm a little new at this and I really don't want to get involved, > > but since my inbox has seen nothing but this for the past day or two, > > I'm going to ask a few questions I'm interested in the answers to... > > First and foremost is, will adding this to the tree be used for > > function creep, whereby the next request to add to/alter the portage > > tree is backed up by "Well, the profile change was already added to > > the tree"? I wouldn't want a precedent like this set without the > > council reviewing it. > > I really don't see much of an issue of feature creep. Gentoo/ALT > already has a profile. It isn't like there are changes to the actual > ebuilds themselves. This is my main point. I believe that adding the profile now will lead to function creep. Given the stated direction of paludis to be INCOMPATTIBLE with portage, this will eventually lead to either replacing portage or forcing portage into directions that gentoo does not wish to go. > > > Thirdly has anything like this ever happened to Debian or the > > Sourcery group? If so how did they cope with it, and if not, how > > have they avoided it? > > SMGL has voting and things get done. Wrong answer. It does not answer the question. SOURCERY!=SMGL > > > As you may have guessed I'm of the, "You can do the same thing with > > an overlay, so why must it be in the tree". I am however willing to > > wait and see what the council says, why can't the changes to the tree > > wait until then, what is so urgent? I'm especially intrigued since > > all this is simply to no longer require portage as a dependency of > > system. Can't paludis peacefully co-exist with a portage > > installation for a little longer, until it's mature? > > The question is when is it mature? I've tried it and Paludis does > work. There will always be bugs and feature requests. Its part of > the development process. It is mature when I can install it in my gentoo system. Try it out on some ebuilds. Check whether my ebuild is compatible with paludis and portage (in the same system), and not break my system horibly. If only undocumented tricks will allow this this means that paludis is not yet mature. Yes, any package manager that claims to work with ebuilds is only mature when it cooperates in a portage environment. This means that either you cooperate with portage, or you get the portage developers to introduce the things you need into a stable portage. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpkDQsShaDS6.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 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 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, 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 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
** 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
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
> > First and foremost is, will adding this to the tree be used for > > function creep, whereby the next request to add to/alter the portage > > tree is backed up by "Well, the profile change was already added to the > > tree"? I wouldn't want a precedent like this set without the council > > reviewing it. > > I really don't see much of an issue of feature creep. Gentoo/ALT > already has a profile. It isn't like there are changes to the actual > ebuilds themselves. Actually there are a lot of packages that need portage to work properly. Portage has never been added to DEPEND because portage is expected to "be just there". With a paludis profile added how are we gonna deal with that? - Adding $package to the paludis package.mask? - Creating a $packagemanager virtual and expect every packagemanager to provide all the functions offered by portage? (E.g. having wrapperscripts for several calls.) - Make ebuilds that explicit depend on portage depend on portage by adding sys-apps/portage to (R)DEPEND? -- Christian Hartmann http://www.gentoo.org/~ian/ PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=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
Mike Auty <[EMAIL PROTECTED]> said: > Forgive me, > I'm a little new at this and I really don't want to get involved, but > since my inbox has seen nothing but this for the past day or two, I'm > going to ask a few questions I'm interested in the answers to... > First and foremost is, will adding this to the tree be used for > function creep, whereby the next request to add to/alter the portage > tree is backed up by "Well, the profile change was already added to the > tree"? I wouldn't want a precedent like this set without the council > reviewing it. I really don't see much of an issue of feature creep. Gentoo/ALT already has a profile. It isn't like there are changes to the actual ebuilds themselves. > Thirdly has anything like this ever happened to Debian or the Sourcery > group? If so how did they cope with it, and if not, how have they > avoided it? SMGL has voting and things get done. > As you may have guessed I'm of the, "You can do the same thing with an > overlay, so why must it be in the tree". I am however willing to wait > and see what the council says, why can't the changes to the tree wait > until then, what is so urgent? I'm especially intrigued since all this > is simply to no longer require portage as a dependency of system. Can't > paludis peacefully co-exist with a portage installation for a little > longer, until it's mature? The question is when is it mature? I've tried it and Paludis does work. There will always be bugs and feature requests. Its part of the development process. Ryan Phillips pgphGkWfkoHSr.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
Stephen Bennett wrote: > 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/. That implies it's going to be added to the tree one way or another. You seem to have misplaced the third option of not adding anything to the tree. Mike 5:) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Forgive me, I'm a little new at this and I really don't want to get involved, but since my inbox has seen nothing but this for the past day or two, I'm going to ask a few questions I'm interested in the answers to... First and foremost is, will adding this to the tree be used for function creep, whereby the next request to add to/alter the portage tree is backed up by "Well, the profile change was already added to the tree"? I wouldn't want a precedent like this set without the council reviewing it. Secondly, is that what's already being done by asking individual arch devs to add individual paludis profiles? Surely paludis would eventually require all archs to be there, or have I missed something (which I may have)? Having already added a file to the profiles directory, which caused a few posts on here earlier, and then having asked the question of all the devs so as to avoid a similar incident, and then received a mixed response, now specific people have been asked if individually they'll help get paludis in the tree. Doesn't that seem a little improper, perhaps? Thirdly has anything like this ever happened to Debian or the Sourcery group? If so how did they cope with it, and if not, how have they avoided it? As you may have guessed I'm of the, "You can do the same thing with an overlay, so why must it be in the tree". I am however willing to wait and see what the council says, why can't the changes to the tree wait until then, what is so urgent? I'm especially intrigued since all this is simply to no longer require portage as a dependency of system. Can't paludis peacefully co-exist with a portage installation for a little longer, until it's mature? Thanks, Mike 5:\ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Stephen Bennett <[EMAIL PROTECTED]> said: > 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. Sub-profiles are included in my statement in the other thread. Please hold off on adding or modifying *anything* until the Council has decided on how we wish to proceed in handling situations like this. -- 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 pgpwU1pKAc0eY.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
Given the sheer volume of impassioned response, regardless of any technical arguments, I'm dropping the top-level profile idea for now. Several architecture teams have expressed an interest in creating sub-profiles under their own, however, and I'll be working with them to get those implemented. Perhaps I'll revisit the top-level idea at a later date when all the fuss has died down. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 21:32:47 + [EMAIL PROTECTED] (Tim Yamin) wrote: | On Wed, May 17, 2006 at 10:30:10PM +0100, Stephen Bennett wrote: | > On Wed, 17 May 2006 20:56:14 + | > [EMAIL PROTECTED] (Tim Yamin) wrote: | > | > > Well, if you're going to have a package manager that delivers the | > > same result as Portage it must therefore work with Catalyst... | > | > Paludis can produce the same end result as Portage. The reason it | > won't work with catalyst is that the interface is different. | | ... so thus you claim it can produce binpkgs (I'm not bothered about | the interface, but the support to produce said binpkg must be there | and also to utilize said binpkg to install things)... and it can't. No, we claim that it can install a system (very suckily and messily, right now, but in the future when we're claiming that it can install a system *nicely*, it won't be in the slightest bit inelegant). | Yes, getting this thread back on-topic would be nice. Then stop taking potshots. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, May 17, 2006 at 11:17:39PM +0100, Stephen Bennett wrote: > Better to stick to reality than invent pink elephants to back up a > completely baseless assertion. Someone should rewrite Godwin's law to include pink elephants. This subthread has gone beyond usefulness. Sorry everyone for the noise and me being a part of this. 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 pgpEIFgiS9amV.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 17:05:31 -0400 Chris Gianelloni <[EMAIL PROTECTED]> wrote: > What do package managers that don't claim, in any way, to be > portage-compatible have to do with *this* package manager that *does*? I don't see paludis claiming that it is portage-compatible anywhere on their website. In fact they specifically tell you that it is not compatible. "Do not try to use Paludis and Portage to install things inside the same root. The config and vdb formats are not compatible!" > Why do people *insist* on trying to add so many levels of indirection > into their "discussions"? 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? ~tcort pgpcwKPp1VmaG.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wed, May 17, 2006 at 10:53:47PM +0200, Wernfried Haas wrote: > On Wed, May 17, 2006 at 11:13:16PM +0200, Christian Birchinger wrote: > > Then you remove the profile just like you would remove any piece > > of software where the license is unacceptable. > > Please look a bit up in the thread, my point was not only the profile > but integrating a package manager we have no control over. > > > The arguments are getting more and more "creative". It's almost > > like asking what we will do when gcc turns into a commercial > > product. > > The package manager is a central piece, if we ever want to change our > package manager we really should think about problems like that. > > > Please try to stay realistic and don't invent strange new > > theoretical problems. > > Better safe then sorry. > It's GPL-2, no? If the license changes before it's a full replacment ... remove the profile. If it changes after it became the standard ... fork it. 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. 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". Christian -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, May 17, 2006 at 10:30:10PM +0100, Stephen Bennett wrote: > On Wed, 17 May 2006 20:56:14 + > [EMAIL PROTECTED] (Tim Yamin) wrote: > > > Well, if you're going to have a package manager that delivers the > > same result as Portage it must therefore work with Catalyst... > > Paludis can produce the same end result as Portage. The reason it won't > work with catalyst is that the interface is different. ... so thus you claim it can produce binpkgs (I'm not bothered about the interface, but the support to produce said binpkg must be there and also to utilize said binpkg to install things)... and it can't. > 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/. Yes, getting this thread back on-topic would be nice. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 17:01:44 -0400 Chris Gianelloni <[EMAIL PROTECTED]> wrote: | This is a simple binary equation. Can paludis provide a | portage-compatible binary package? No. This means it does not give | the same end result. Period. The desired end result is installing a system. Paludis can do that already, if you really want, and it will be able to do it much more elegantly 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
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. | This is completely unacceptable to Release Engineering, and as such, | it is my recommendation that no support be added to the *portage* | tree to support paludis. 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. -- 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:05:31 -0400 Chris Gianelloni <[EMAIL PROTECTED]> wrote: | Why do people *insist* on trying to add so many levels of indirection | into their "discussions"? Because some people insist upon trying to attack Paludis via FUD and keep on trying to add in entirely irrelevant 'requirements' that have nothing to do with the original topic? -- 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 16:55:17 -0400 Chris Gianelloni <[EMAIL PROTECTED]> wrote: | On Wed, 2006-05-17 at 20:55 +0100, Ciaran McCreesh wrote: | > The plan, which may be full of holes, may change and may just be me | > being crazy, is to replace using a stage with something like: | | OK. So not only are you planning on replacing portage, you're | planning on replacing Release Engineering. Thanks, but we are not | interested. Not so much replacing as removing the need for. | > paludis --config-suffix install --install system | > | > which will then go off and grab the relevant binary packages from a | > remote location and merge them onto ROOT. Being able to do something | > along these lines is a) one of several reasons for --config-suffix | > and b) a large part of why I don't want to use the Portage tbz2 | > format, where metadata and contents aren't separated. | | Remote location, huh? What about non-networked installations? Remote location can be somewhere else on a filesystem. | > Assuming the above ends up not being insane, then yes. | | Which would have to be accepted by the Release Engineering project. | Perhaps this point has been lost on you up until now. *shrug* Not an issue. The whole thing removes the need for traditional releases. | > I'm pretty sure it would be easier to just not use anything in the | > installer that relies upon VDB when using Paludis. The installer | > code is flexible enough to make this not to tricky. | | You mean like *all* of the GRP-handling code? Also no longer 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 20:56:14 + [EMAIL PROTECTED] (Tim Yamin) wrote: > Well, if you're going to have a package manager that delivers the > same result as Portage it must therefore work with Catalyst... Paludis can produce the same end result as Portage. The reason it won't work with catalyst is that the interface is different. Once again, this is going far beyond the scope of the initial discussion. I'm not saying that Paludis should replace Portage, nor that it should be an "officially supported package manager". The question is simply one of whether I can add a top-level paludis profile without people complaining overmuch, or whether I have to go through the arch teams and make sub-profiles in 4 different places under default-linux/. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, 17 May 2006 13:43:04 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: | Instead of on the fly generation of the virtuals pkgs (as | pkgcore/portage do), you've flattened them into an actual on disk vdb | entry? Not really. A fake package is generated for the virtual (rather than just renaming it to another package), and that gets installed into VDB. | Re: incompatibility, that can be dealt with by generating a fake | ebuild- already generate an env from the looks of it (not seeing | anything in RDEPEND/DEPEND however). Would still confuse Portage somewhat, at least whilst people still use old style virtuals. | > And that's exactly it. At what point does something stop being API | > and start being "someone is doing illegal things with internals"? | | Common sense. And it's common sense that we've been using all along on the API issue. | Did something similar with ebuild-shell- folks for the most part | liked it. | | Meanwhile... get cracking, you'll see far more local assumptions | transitioning between phases then transitioning between groupped | merge phases -> groupped unmerge phases *shrug* If you want that feature in a hurry, you're more than welcome to submit a patch. Otherwise it's considered less important than user mirrors, binaries, sdepend etc. And, uh, the local vars will still work just fine even with break functions. | 'Cept EAPI was specifically targeted at bash based ebuilds only. | Alternative formats (non bash fex), expected folks to solve that | issue themselves (since I didn't see a sane general solution to it). | | For what EAPI is defined as, portage supports it fully. Sure, no-one sane is going to start using XML ebuilds. They might, however, reasonably want the behaviour of 'inherit' to change. -- 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 22:53:47 +0200 Wernfried Haas <[EMAIL PROTECTED]> wrote: > > The arguments are getting more and more "creative". It's almost > > like asking what we will do when gcc turns into a commercial > > product. > > The package manager is a central piece, if we ever want to change our > package manager we really should think about problems like that. So's the toolchain. > > Please try to stay realistic and don't invent strange new > > theoretical problems. > > Better safe then sorry. Better to stick to reality than invent pink elephants to back up a completely baseless assertion. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Wed, 2006-05-17 at 16:26 +, Thomas Cort wrote: > On Wed, 17 May 2006 15:48:04 -0400 > Chris Gianelloni <[EMAIL PROTECTED]> wrote: > > I also recommend that the package is masked in all > > Gentoo profiles where a release is built against, since again, it is > > 100% incompatible and upstream has now said that they have no intentions > > on making it compatible. > > rpm, stow, and dpkg are 100% incompatible with portage and I'm fairly certain > that upstream has no intentions of making them compatible, yet they are in > the tree and stable on many arches. Are you also suggesting that we mask them > too? What do package managers that don't claim, in any way, to be portage-compatible have to do with *this* package manager that *does*? One of the goals of this package is to be a portage replacement/alternative. Why do people *insist* on trying to add so many levels of indirection into their "discussions"? Do you really think that attempting to confuse a situation makes it any easier to reach a solution? Are you arguing for the sake of arguing? Perhaps you just like to hear yourself talk? -- 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, 2006-05-17 at 21:22 +0100, Ciaran McCreesh wrote: > On Wed, 17 May 2006 16:12:09 -0400 Daniel Ostrow <[EMAIL PROTECTED]> > wrote: > | Unfortunately in this case there is only one cat, he has only one skin > | and there is only one knife with which to skin him. Chris asked if > | paludis can build a release (meaning an official Gentoo release), > | which means following the Release Guidelines to the letter. > > If you look at it that way (which isn't what he actually asked to begin > with), then the question is "is Paludis identical to Portage?", which > it clearly isn't. A more useful question is "can Paludis give the same > end result as Portage?". It can not. Paludis, by your own admission, can not and will not build portage-compatible binary packages. This is a simple binary equation. Can paludis provide a portage-compatible binary package? No. This means it does not give the same end result. Period. -- 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, 2006-05-17 at 21:13 +0100, Ciaran McCreesh wrote: > On Wed, 17 May 2006 15:48:04 -0400 Chris Gianelloni > <[EMAIL PROTECTED]> wrote: > | My recommendation, as Release Engineering Strategic Lead, is that no > | profiles be added to the tree, nor any modifications be made to any > | current profile, including base or the profiles directory, until such > | time that Paludis is actually a usable package manager for building a > | Gentoo release. I also recommend that the package is masked in all > | Gentoo profiles where a release is built against, since again, it is > | 100% incompatible and upstream has now said that they have no > | intentions on making it compatible. As I see it, the original > | question posed to this list is now a non-issue. It will *never* be > | portage compatible enough, according to the lead developer, to ever > | be usable as a portage replacement or alternative. > > So what you're saying is that until Paludis is called Portage and is > identical to Portage, it's a no go. Which is clearly crazy talk, since > Paludis can already be used to install a system from scratch -- it just > does so differently. See, this is why people have problems having a discussion with you. You inject your own ideas and thoughts into their words and beat around the bush so much that it is impossible to tell what the hell you're actually trying to say. Never once did I say that it must be called portage. Never once did I say that it must support all of the features of portage. That is *you* saying that I said something that I have not. It is you flat out lying. Quite simply, I'm not surprised. Here's what I am trying to say plainly. 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. This is completely unacceptable to Release Engineering, and as such, it is my recommendation that no support be added to the *portage* tree to support paludis. -- 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, 2006-05-17 at 20:55 +0100, Ciaran McCreesh wrote: > The plan, which may be full of holes, may change and may just be me > being crazy, is to replace using a stage with something like: OK. So not only are you planning on replacing portage, you're planning on replacing Release Engineering. Thanks, but we are not interested. > paludis --config-suffix install --install system > > which will then go off and grab the relevant binary packages from a > remote location and merge them onto ROOT. Being able to do something > along these lines is a) one of several reasons for --config-suffix and > b) a large part of why I don't want to use the Portage tbz2 format, > where metadata and contents aren't separated. Remote location, huh? What about non-networked installations? > | > | #2. Can paludis build all of the release materials required by the > | > | Release Engineering release guidelines? > | > > | > No. Nor will it ever, nor will it need to. > | > | Will you then instead try to create new guidelines that do result > | into development of releases? > > Assuming the above ends up not being insane, then yes. Which would have to be accepted by the Release Engineering project. Perhaps this point has been lost on you up until now. > | > | #3. Can paludis build a portage-compatible VDB that can be used > | > | by the Gentoo Linux Installer? > | > > | > No. Nor will it ever, nor will it need to. > | > | Why will it not need to? Usage and support of paludis would be a lot > | greater it it could work (with limited feature perhaps) on a portage > | compatible VDB. You might work with the portage team to have portage > | be aware of extensions in the VDB and handle them smartly (ignore > | them?). At that point paludis could offer extra features while being > | still portage compatible. > > I'm pretty sure it would be easier to just not use anything in the > installer that relies upon VDB when using Paludis. The installer code > is flexible enough to make this not to tricky. You mean like *all* of the GRP-handling code? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
