Re: [gentoo-dev] Signing everything, for fun and for profit
This email is a discussion on why we need to care about more than the simple key parameters, and why - this includes things like changing the validity of an existing key. We also need to consider: location of key (primary key vs. subkey), expiry policies (expiries are only one element of key validity), key signatures, and revoking elements in a key. I've tried very hard to ensure absolutely all of the following is completely fact, and that I have not entered any of my opinions into it, except where I've explictly marked it as such. On Thu, May 18, 2006 at 11:45:17PM +0200, Patrick Lauer wrote: > Key policies > > To make signing relevant and verifiable all devs should use the same > parameters - key length, key type, validity. No, the simple parameters of the have little bearing on how they are used. While we do care about them in terms of managing file signatures, some understanding is needed first. Introduction The following is an introduction into some of the OpenPGP standard, with a focus on how it affects file signing, key signing, management of keys (for the complex style listed), and revocation. It's important as to what attacks against a key can lead to what results. Breakdown of what is a 'key' is --- A 'key' under PGP/GnuPG (OpenPGP) consists of several important entities: 1. *actual cryptographic primary keys and secondary keys (subkeys) [pub/sub] 2. *user ids - one uid per email address [uid] 3. signatures, each attached to one uid [sig] 4. revocations of any of the above items [rev] I've included the packet type name in the [] at the end. The first two items marked with a * are the core entities, and items are associated with only one element of them. There are a few more packet types, but they aren't important to our discussion. After this point, I will use the term 'cryptokey' to refer to the actual cryptographic keys, and the generic term 'key' to refer to the collection of above items. To see the various elements of the above, try this: "gpg --list-sig [EMAIL PROTECTED]" If you look at my key, it goes on for a few pages (but isn't quite as long as the Paludis thread). The first column has the information type, and you'll see the types I mentioned above. Now let's focus on a single key for a moment: # gpg --edit-key [EMAIL PROTECTED] ... pub 1024D/34884E85 created: 2002-08-27 expires: 2008-03-09 usage: CS trust: ultimate validity: ultimate sub 2048g/CA05A397 created: 2002-08-27 expires: 2008-03-09 usage: E sub 2048g/67592A1F created: 2003-04-12 expires: 2008-03-09 usage: E This key was revoked on 2004-09-09 by DSA key 34884E85 Robin Hugh Johnson <[EMAIL PROTECTED]> sub 1024D/FB33B3A4 created: 2002-08-27 revoked: 2004-09-09 usage: SA This key was revoked on 2004-09-09 by DSA key 34884E85 Robin Hugh Johnson <[EMAIL PROTECTED]> sub 2048g/CC772FC3 created: 2002-08-27 revoked: 2004-09-09 usage: E sub 1024D/3233C22C created: 2004-08-29 expires: 2008-03-09 usage: S [ultimate] (1). Robin Hugh Johnson <[EMAIL PROTECTED]> [ revoked] (2) Robin Hugh Johnson <[EMAIL PROTECTED]> [ultimate] (3) Robin Hugh Johnson <[EMAIL PROTECTED]> [ultimate] (4) Robin Hugh Johnson <[EMAIL PROTECTED]> [ revoked] (5) Robin Hugh Johnson <[EMAIL PROTECTED]> [ revoked] (6) Robin Hugh Johnson <[EMAIL PROTECTED]> [ revoked] (7) Robin Hugh Johnson <[EMAIL PROTECTED]> [ revoked] (8) Robin Hugh Johnson <[EMAIL PROTECTED]> [ revoked] (9) Robin Hugh Johnson <[EMAIL PROTECTED]> The important bit here is the 'usage:' bit at the end of the cryptokeys. There are 4 letters that will appear here: C - Certify S - Sign E - Encrypt A - Authenticate We are interested in two of these only: Certify and Sign. We aren't dealing with encrypted data at the moment, and usage of authenticate is not implemented in gpg-1.4. 'Certify' is the terminology used for signing uids. 'Sign' is the terminology used for digitally signing files/data. If you attend a keysigning event, you are certifying that a uid does indeed belong to a person (more on this in a moment, in how we can gain from it). From this point forward, I will use 'certify' to indicate signing of a key, and signing to indicate other data signing. Only the primary cryptokey [pub] will ever be marked with Certify. The primary cryptokey is used for all uid signatures made with your key. It also protects your key itself from some modifications by attackers. Having multiple UIDs allows a person to go over several email addresses over time, without having to invalidate old correspondence, or identify themselves to any given third party more than once. Choice of Length/Type: -- Any of the cryptokeys marked with Sign will be used in signing Manifest/digest data. We have a few choices for these - I'm limiting this to what is implemented in upstream GnuPG, and not anything added by external patches. CryptoKey types: DSA, RSA. CryptoKey len
Re: [gentoo-dev] New git.eclass
Duncan Coutts wrote: > In case anyone needs distracting from a current hot topic... > > Just like we have eclasses for cvs, tla etc, kosmikus has written one > that does the same thing but for darcs. s/kosmikus has/I have/, s/darcs/git/ > Darcs (dev-util/darcs) is one of the new breed of distributed source s/Darcs (dev-util/darcs)/Git (dev-util/git) > control systems. Many projects are now maintaining their development > sources in darcs, hence the utility of this eclass: s/darcs/git/ Available in my overlay [1] and used in libX11- and cairo-. Thanks, Donnie 1. http://dev.gentoo.org/~spyderous/overlay/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: 259 paludis-profile messages. ENOUGH!
On 18/05/06, Chris White <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE-Hash: SHA1On Thu, 18 May 2006 17:08:17 -0400Peter <[EMAIL PROTECTED]> wrote:> On Thu, 18 May 2006 22:01:42 +0100, Ciaran McCreesh wrote: >> > Then learn how to use your mail client.> >> > And hey, look, by starting yet another thread you're just making> > noise in an attempt to justify a personal grudge, thus making > > things harder for the people who do real work around here. If you> > don't have anything useful to contribute, shut up and go away.> >>> Ciaram, I was actually sticking up for you and spb. I said nothing > about you or anyone else -- just the project. As usual though, you> take something and turn it into something it isn't and respond with> insults.Relax! Grab some popcorn, enjoy the show! 30 mile threads is what makes real linux distros real. We actually use them to provide a meansof cooking for the weekly dev BBQ's. Anyways, at this point I'd callit it a day and say "Hey everyone, let's all go to IRC"! With that you could probably reduce the thread count by 40%.You could try telling people to sort their conversation into logicalstructure.. but last time I tried that, Ciaranm put up a procmail ruleon how to nuke all mails from me, and someone else told me to pretty much shove it. No love lolz!So here's $5.00, grab some popcorn and soda and enjoy the show!Chris White-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.2.2 (GNU/Linux)iD8DBQFEbAuRFdQwWVoAgN4RAqrnAJ94aXQ4QdwXIG+V8RpRFE8uqLXn6QCgmz+w XHY3AG3QBGIosaGSJfogNEs==RTSY-END PGP SIGNATURE---gentoo-dev@gentoo.org mailing list/me points the first finger
Re: [gentoo-dev] Re: 259 paludis-profile messages. ENOUGH!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 18 May 2006 17:08:17 -0400 Peter <[EMAIL PROTECTED]> wrote: > On Thu, 18 May 2006 22:01:42 +0100, Ciaran McCreesh wrote: > > > Then learn how to use your mail client. > > > > And hey, look, by starting yet another thread you're just making > > noise in an attempt to justify a personal grudge, thus making > > things harder for the people who do real work around here. If you > > don't have anything useful to contribute, shut up and go away. > > > > Ciaram, I was actually sticking up for you and spb. I said nothing > about you or anyone else -- just the project. As usual though, you > take something and turn it into something it isn't and respond with > insults. Relax! Grab some popcorn, enjoy the show! 30 mile threads is what makes real linux distros real. We actually use them to provide a means of cooking for the weekly dev BBQ's. Anyways, at this point I'd call it it a day and say "Hey everyone, let's all go to IRC"! With that you could probably reduce the thread count by 40%. You could try telling people to sort their conversation into logical structure.. but last time I tried that, Ciaranm put up a procmail rule on how to nuke all mails from me, and someone else told me to pretty much shove it. No love lolz! So here's $5.00, grab some popcorn and soda and enjoy the show! Chris White -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEbAuRFdQwWVoAgN4RAqrnAJ94aXQ4QdwXIG+V8RpRFE8uqLXn6QCgmz+w XHY3AG3QBGIosaGSJfogNEs= =RTSY -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Signing everything, for fun and for profit
On Fri, 19 May 2006 01:53:29 +0200 "Kevin F. Quinn" <[EMAIL PROTECTED]> wrote: | obviously header.txt and skel.* aren't important. scripts isn't too | important either, although a manifest-style file in there wouldn't be | difficult. licenses and metadata don't have any security impact so | there's little point there, also. metadata has security impact. | do profiles present a security risk? Perhaps by masking/unmasking | fixed/vulnerable versions of packages. Or by using a bashrc, perhaps? Profiles most definitely do have security impact. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Signing everything, for fun and for profit
On Thu, 18 May 2006 23:45:17 +0200 Patrick Lauer <[EMAIL PROTECTED]> wrote: > Note: a possible defense against rogue devs would be multi-signing, I don't think it's worth trying to defend against rogue devs. We have to have some level of trust amongst devs; anyone abusing that trust will be ejected sooner or later and any breakage will be fixed. On key management - I wouldn't get too excited about gold standard key management. Using the "web of trust" seems good enough to me. The default chain depth of 5 seems enough to reach around the globe. Publish the top-level public key(s) and fingerprint(s) on the web server, have the secret keys held by infra, revocation certificates by infra and council. Anyone not wishing to trust the web server can locate a nearby dev whose identity they can trust with a chain back to the top and obtain the public key from that dev. Perhaps we could take a more proactive approach to getting devs keys onto the chain. I wanted to mention the currently un-signed portions of the tree. I'm sure we've discussed this before although I couldn't find it. Unsigned bits of the rsync tree are: eclass licenses metadata profiles header.txt scripts skel.* obviously header.txt and skel.* aren't important. scripts isn't too important either, although a manifest-style file in there wouldn't be difficult. licenses and metadata don't have any security impact so there's little point there, also. do profiles present a security risk? Perhaps by masking/unmasking fixed/vulnerable versions of packages. Here, a Manifest in each directory seems most sensible (it might be useful to move the global data around a bit; fex move *desc into the desc subdirectory). eclass - not so easy. A per-eclass detached signature would clutter the directoryup too much, doubling the file count. A single Manifest for the whole directory could be awkward if enough eclass editing goes on simultaneously, but it might be workable. I think that's where the last discussion ended up - a single manifest for the whole eclass directory. If GLEP33 ever gets implemented, this issue is obvious as each subdirectory would have its own manifest. Obviously the best way to add this sort of thing is to add support to repoman, which has been mentioned before for profiles at least, for QA. -- Kevin F. Quinn signature.asc 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
[gentoo-dev] New darcs.eclass
In case anyone needs distracting from a current hot topic... Just like we have eclasses for cvs, tla etc, kosmikus has written one that does the same thing but for darcs. Darcs (dev-util/darcs) is one of the new breed of distributed source control systems. Many projects are now maintaining their development sources in darcs, hence the utility of this eclass: http://haskell.org/~gentoo/gentoo-haskell/portage/eclass/darcs.eclass kosmikus adapted it from the cvs and tla eclasses. We've been using it for some time in the Haskell team's overlay and we've had a request to include it in the main tree. http://bugs.gentoo.org/show_bug.cgi?id=128307 That request includes an implementation but we're proposing our own implementation that is a bit more sophisticated and has already been tested with a few *-darcs ebuilds. So we'd like to have people's opinion/comments on this going into the tree and of course we would appreciate code review etc. -- Duncan Coutts : Gentoo Developer (Haskell team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Signing everything, for fun and for profit
Hello all,
I flood you again with a long email. Apologies to all that don't
want to read so much, but it is a problem of rather high importance that
has not really been fixed, and the first discussions happened in 2003 as
far as I can tell. Time to FIX IT!!!
The problem, in short, is how to handle the checksumming and signing of
gentoo-provided files so that manipulation by external entities becomes
difficult. I expect many disagreements on the "best" strategy to
implement, but I hope that a sensible compromise will be reached so that
this can finally be implemented.
All the lazy people may stop reading here ;-)
Short overview:
The Problem
The Attacker
Defending
Policies and open problems
The Problem:
A malicious person could modify the files provided by Gentoo to
manipulate and take over the computers of Gentoo users. To avoid such
problems all files provided and used by Gentoo need to be identifiable
as "correct" - we need integrity checks.
An attacker should not be able to easily circumvent these checks. There
are some attacks that can't be prevented, so we also have to see the
practical limits of any scheme we define - for example an attacker
could
be a Gentoo dev with full access to all ressources, stopping that
person
will be more difficult (if not impossible) than stopping a random
script
kiddie that hax0rs a distfile mirror with a 0-day exploit.
The files
=
There are two groups of files at the moment that need to be secured:
- distfiles: The large archives of source code and binary blobs from
which we install a package
- "the tree": metadata, ebuilds and patches containing all the
information to manage the local software installation.
The default distribution methods are rsync for the tree and http/ftp
for
distfiles. As there are too many users for a single server theservers
are
provided by external contributors and are not directly controlled by
Gentoo. In almost all cases a fallback to the original download
location
of a file is provided.
The Attacker
Any security policy has to take into account how strong an attacker is.
For example securing against your grandmother with checksums signed by
multiple independent persons is most likely overkill. A simple checksum
would most likely be enough there.
On the other end of the spectrum we have aliens that can crack any
encryption scheme in roughly two minutes, obviously we can't do
anything
to really stop them.
What attackers are then reasonable?
- the script kiddie that takes over one single mirror
- a large multinational monopolist that tries to sabotage any potential
competitors
- a mirror operator that has a bad days and manipulates files for fun
- a really strong hax0r that takes over the Gentoo CVS server
- a social hacker that takes a dev hostage and forces that dev to
insert
evil bad data
This is by far not a complete list, it should only help with figuring
out what can go wrong.
Now let's classify the attackers:
* local attacker ("your roommate") - nothing we can defend against,
your
responsability.
* single compromised mirror - only with checksums can this be found. If
the checksums are distributed on a different path than the distfiles
a single compromised mirror has a very low impact as checksums don't
match.
* compromised rsync mirror - now the checksums can be forged. The
attacker will have to change the SRC_URI too so that only the
compromised distfiles are transferred. Also changes in the ebuilds must
be considered - a "rm -rf" in the right place in an ebuild will have a
large impact and can't be caught with checksums (since those could be
forged by the same attacker). We need signed checksums here.
* compromised developer - this is hard to detect, but once detected all
files involved can be checked and corrected. The impact of this is very
high, it is very difficult to avoid. (So we just assume that no dev
will
go berserk and look for low-impact methods that allow us to clean up if
that ever happens)
Note: a possible defense against rogue devs would be multi-signing, i.e.
having all commits checked by at least one other person. This does not
help much as there can be collusion between devs and the impact on all
devs is very high. It would effectively deadlock Gentoo and prevent any
useful progress.
Defense methods
===
1) Checksums
A Checksum is a one-way function that returns a constant-length
identifier. The checksum is designed so that changing one bit in the
input totally changes the output (quite simplified, but that's all that
matters). Thus any changes to a file lead to a bad checksum, finding a
collision (two files with the same checksum) is hard.
Some checksum algorithms have known weaknesses, so relying on a single
algorithm is not advised. For example MD5 suffers from precomputation
attacks where one can generate two files with equal checksums (but it
is
not possible to find a matching second file to a given file).
Re: [gentoo-dev] 259 paludis-profile messages. ENOUGH!
Ciaran McCreesh wrote: [Thu May 18 2006, 04:01:42PM CDT] > On Thu, 18 May 2006 16:41:09 -0400 Peter <[EMAIL PROTECTED]> wrote: > | However, continuing the thread serves no useful purpose except, IMHO, > | to completely obfuscate the original point of the thread > > Nonsense. There is still productive discussion going on in that thread. > The only reason it is so noisy is because a small group of malcontents > who hold grudges against some of the Paludis developers. That's not entirely fair. In the case of both pauldv and wolf31o2, I suspect that holding grudges was not the reason for the heightened tempers. Instead, it looked to me like both devs had very strong opinions on what an alternative package manager should do, and neither was happy with the fact that paludis would work differently. Consequently, they both attacked paludis quite strongly, asserting their opinions as "obvious" facts, and received strongly-worded, not entirely helpful counterarguments in return. A larger dose of patience, or perhaps a few controlled substances, would have dramatically lowered the heat. Despite all that, there's been a lot of useful content in this thread. > | While I am completely against any form of censorship, I certainly > | wish I had the ability to block that thread and all further postings > | to it. > > Then learn how to use your mail client. I wouldn't have stated it that way, but a threaded mail client does work wonders for this sort of thing. Both mutt and thunderbird, for example, allow one to fold, delete, or otherwise just ignore a thread quite nicely. > And hey, look, by starting yet another thread you're just making noise > in an attempt to justify a personal grudge, thus making things harder > for the people who do real work around here. If you don't have anything > useful to contribute, shut up and go away. *Sigh* Be nice, please. Incidentally, he did have a point that this thread is now darn hard to follow. Perhaps it's time to split off a thread or two...? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgprUHyLJIiJN.pgp Description: PGP signature
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
[gentoo-dev] Re: 259 paludis-profile messages. ENOUGH!
On Thu, 18 May 2006 22:01:42 +0100, Ciaran McCreesh wrote: > Then learn how to use your mail client. > > And hey, look, by starting yet another thread you're just making noise > in an attempt to justify a personal grudge, thus making things harder > for the people who do real work around here. If you don't have anything > useful to contribute, shut up and go away. > Ciaram, I was actually sticking up for you and spb. I said nothing about you or anyone else -- just the project. As usual though, you take something and turn it into something it isn't and respond with insults. -- Peter -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 259 paludis-profile messages. ENOUGH!
On Thu, 18 May 2006 16:41:09 -0400 Peter <[EMAIL PROTECTED]> wrote: > So, while I am not endorsing pablum, at least let's cut the thread. I > see nothing useful coming from it anymore. While you may not see it, there are still useful points being raised. If you don't want to read it, don't. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 259 paludis-profile messages. ENOUGH!
On Thu, 18 May 2006 16:41:09 -0400 Peter <[EMAIL PROTECTED]> wrote: | However, continuing the thread serves no useful purpose except, IMHO, | to completely obfuscate the original point of the thread Nonsense. There is still productive discussion going on in that thread. The only reason it is so noisy is because a small group of malcontents who hold grudges against some of the Paludis developers. | While I am completely against any form of censorship, I certainly | wish I had the ability to block that thread and all further postings | to it. Then learn how to use your mail client. And hey, look, by starting yet another thread you're just making noise in an attempt to justify a personal grudge, thus making things harder for the people who do real work around here. If you don't have anything useful to contribute, shut up and go away. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Ciaran McCreesh: > And that's your argument? If you're just going to sink to accusing > anyone who disagrees with you of trolling then please retire gracefully > before you make an even bigger fool of yourself. That's indeed funny. /me wrote: > That actually was a serious question. But you and your gang are good in > avoiding answering questions that you are not comfortable with. Now you are doing it again. - Even funnier that you cc'd devrel. Ciaran McCreesh: > I was hoping you could > continue providing constructive input as you were earlier on in the > thread That's what you are really after? I'm still waiting for you to answer my questions then. -- Christian Hartmann http://www.gentoo.org/~ian/ PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=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] 259 paludis-profile messages. ENOUGH!
Peter wrote: Imagine a new user or visitor trolling this ML. They want to learn more about Gentoo. Then they come across the Paludis thread. How TF can they possibly follow what is going on? Then, as the thread wears on it degenerates into more personal attacks. So it's Bennett/McCreesh against the world. OK. However, continuing the thread serves no useful purpose except, IMHO, to completely obfuscate the original point of the thread -- to allow paludis to have a profile or sub profile and/or whether or not it should be on the tree or in an overlay. While I am completely against any form of censorship, I certainly wish I had the ability to block that thread and all further postings to it. Maybe paludis can set up a blog on the berlios site? There are many important issues that have surfaces WRT paludis that affect the core of gentoo (pun intended). These issues cannot be resolved on a ML. There appear to be certain policy issues that the council needs to resolve. So, while I am not endorsing pablum, at least let's cut the thread. I see nothing useful coming from it anymore. No one forces you to read, feel free to ignore this thread, others are gleaning useful information from it. -Alec Warner -- 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] RFC: etiquette enforcement
On Thu, 2006-05-18 at 14:54 -0500, Mike Doty wrote: > Developer relations has started a discussion about how to handle > etiquette problems on public communication channels. The discussion is > currently taking place on the gentoo-devrel mailing list. This list is > public and we appreciate anyone who has constructive input to provide. > > If you don't want to participate in the discussion but still want to > follow it, the gentoo-devrel ML is archived at > http://dir.gmane.org/gmane.linux.gentoo.devrel I like the idea. While I'm not sure it can be implemented in a fair and sane fashion I hope y'all can find a policy that helps to improve communication. Thanks for your efforts, Patrick -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
[gentoo-dev] 259 paludis-profile messages. ENOUGH!
Imagine a new user or visitor trolling this ML. They want to learn more about Gentoo. Then they come across the Paludis thread. How TF can they possibly follow what is going on? Then, as the thread wears on it degenerates into more personal attacks. So it's Bennett/McCreesh against the world. OK. However, continuing the thread serves no useful purpose except, IMHO, to completely obfuscate the original point of the thread -- to allow paludis to have a profile or sub profile and/or whether or not it should be on the tree or in an overlay. While I am completely against any form of censorship, I certainly wish I had the ability to block that thread and all further postings to it. Maybe paludis can set up a blog on the berlios site? There are many important issues that have surfaces WRT paludis that affect the core of gentoo (pun intended). These issues cannot be resolved on a ML. There appear to be certain policy issues that the council needs to resolve. So, while I am not endorsing pablum, at least let's cut the thread. I see nothing useful coming from it anymore. -- Peter -- 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
[gentoo-dev] RFC: etiquette enforcement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All- Developer relations has started a discussion about how to handle etiquette problems on public communication channels. The discussion is currently taking place on the gentoo-devrel mailing list. This list is public and we appreciate anyone who has constructive input to provide. If you don't want to participate in the discussion but still want to follow it, the gentoo-devrel ML is archived at http://dir.gmane.org/gmane.linux.gentoo.devrel - -- === Mike Doty [EMAIL PROTECTED] Gentoo/AMD64 Strategic Lead PGP Key: 0xA797C7A7 Gentoo Developer Relations ===GPG Fingerprint=== 0094 7F06 913E 78D6 F1BB 06BA D0AD D125 A797 C7A7 === -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEbNDg0K3RJaeXx6cRApYlAKDHejPpSVOZ5nEIIwCtItGghwCCwQCgjdoo rt+yCQo0w8Vv75+WLEAx9bU= =QlVC -END PGP SIGNATURE- -- 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] Alternative Gentoo package managers discussion request (for the council)
On Thu, 18 May 2006 17:19:26 +0100 Edward Catmur <[EMAIL PROTECTED]> wrote: > But Paludis supports multiple inheritance. Would it be feasible to > have Paludis users create /etc/make.profile as a directory, > with /etc/make.profile/parent inheriting from both their chosen > gentoo-x86 profile and a profile in the paludis tree? Certainly possible, and even possible without doing anything ugly if we extend the inheritance to allow for paths specified relative to a named repository. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 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
[gentoo-dev] Last rites for dev-util/cvsutils
This package is currently without a maintainer and has open QA issues; bug #123708. It was marked as testing on every arch without being tested and could really use someone to clean it up. It will be booted in 30 days if no one wants to keep it around. Thanks, -- 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 pgp4PXcAamgWx.pgp Description: PGP signature
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On Thu, 2006-05-18 at 16:37 +0200, Paul de Vrieze wrote: > On Thursday 18 May 2006 16:03, Stephen Bennett wrote: > > On Thu, 18 May 2006 15:34:28 +0200 > > > > Paul de Vrieze <[EMAIL PROTECTED]> wrote: > > > Requiring duplication of profiles for every package manager. > > > > It requires duplicating nothing. This is exactly why we have cascading > > profiles. > > Cascading profiles form a tree with N nodes. Some of these nodes are > abstract in the sense that they are not directly usable. Say that leaves > M possible profiles. To have paludis be on par with portage, each of > these M profiles would have a leaf added for paludis. The same holds for > pkgcore and for any other package manager. This would mean that we have > N+2M profiles. With a paludis and pkgcore toplevel profile this would > even be worse and amount to approximately 3N profiles. > > In the leaf version, all M paludis specific profiles are equal. But Paludis supports multiple inheritance. Would it be feasible to have Paludis users create /etc/make.profile as a directory, with /etc/make.profile/parent inheriting from both their chosen gentoo-x86 profile and a profile in the paludis tree? (I guess this looks like offering a technical solution to a political problem... sorry about that.) Ed -- 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] Alternative Gentoo package managers discussion request (for the council)
On Thu, 18 May 2006 16:37:00 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > Cascading profiles form a tree with N nodes. Some of these nodes are > abstract in the sense that they are not directly usable. Say that > leaves M possible profiles. To have paludis be on par with portage, > each of these M profiles would have a leaf added for paludis. The > same holds for pkgcore and for any other package manager. This would > mean that we have N+2M profiles. With a paludis and pkgcore toplevel > profile this would even be worse and amount to approximately 3N > profiles. > > In the leaf version, all M paludis specific profiles are equal. OK, a valid technical objection. The way to avoid this, as I see it, is to remove all direct references to Portage and its dependencies (Python?) from the system set, and replace them with the virtual. Then make sure that no package assumes that Python will be in system, and explicitly depends on it where necessary. At that point, a system could sanely be installed with any package manager by installing it before the rest of the system set. Long term this is possibly a better solution, but in the short term it requires an order of magnitude more effort, and has a significant effect on every profile in the tree. My original intention was to avoid having to change anything for other developers or people who still want to use Portage. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 16: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] Alternative Gentoo package managers discussion request (for the council)
On Thursday 18 May 2006 16:03, Stephen Bennett wrote: > On Thu, 18 May 2006 15:34:28 +0200 > > Paul de Vrieze <[EMAIL PROTECTED]> wrote: > > Requiring duplication of profiles for every package manager. > > It requires duplicating nothing. This is exactly why we have cascading > profiles. Cascading profiles form a tree with N nodes. Some of these nodes are abstract in the sense that they are not directly usable. Say that leaves M possible profiles. To have paludis be on par with portage, each of these M profiles would have a leaf added for paludis. The same holds for pkgcore and for any other package manager. This would mean that we have N+2M profiles. With a paludis and pkgcore toplevel profile this would even be worse and amount to approximately 3N profiles. In the leaf version, all M paludis specific profiles are equal. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpp4sTC7jM04.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] New eclass db-use
On Thursday 18 May 2006 15:49, Simon Stelling wrote: > Paul de Vrieze wrote: > > Unfortunately this GLEP has not been implemented yet. This eclass > > would indeed be an ideal elib. Also, for this eclass the API > > requirements are not as strict as it is only intended to be used in > > unpack and compile stages. > > That's not my point. I mentioned it because it briefly shows why the > current eclass system has its problems and why contacting -dev *before* > adding a new eclass to the tree is essential. I see your point. This GLEP does not require contacting -dev at all though. Instead of this eclass I could have abused the db4fix eclass and be done with it. The new one has a better name, and sane design. It offers functions (and will offer more) that are long due and actually help ebuilds using berkeley db. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpMLoZNa12tG.pgp Description: PGP signature
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On Thu, 18 May 2006 15:34:28 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > Requiring duplication of profiles for every package manager. It requires duplicating nothing. This is exactly why we have cascading profiles. > Profiles determine what defaults are, and on some level what is > installed. What useflags are supported, and some other things. > > Profiles do not determine how something is installed. A package > manager determines how things are installed. As such any profile > should work with the package manager. And any profile does work with the package manager. What I want to change in the profile is exactly what is installed by default, which is as you say precisely what profiles are for. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 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] New eclass db-use
Paul de Vrieze wrote: Unfortunately this GLEP has not been implemented yet. This eclass would indeed be an ideal elib. Also, for this eclass the API requirements are not as strict as it is only intended to be used in unpack and compile stages. That's not my point. I mentioned it because it briefly shows why the current eclass system has its problems and why contacting -dev *before* adding a new eclass to the tree is essential. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New eclass db-use
On Thursday 18 May 2006 15:06, Simon Stelling wrote: > Paul de Vrieze wrote: > > It has not been. As far as I know such a requirement does not exist. > > In > > It does. The reason for it is pretty good, as kloeri mentioned: The API > of an eclass may never change. See GLEP 33 for some horror scenarios > [1] ;) Unfortunately this GLEP has not been implemented yet. This eclass would indeed be an ideal elib. Also, for this eclass the API requirements are not as strict as it is only intended to be used in unpack and compile stages. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpwYX4EHPlx1.pgp Description: PGP signature
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On Thursday 18 May 2006 14:16, Stephen Bennett wrote: > On Thu, 18 May 2006 12:49:29 +0200 > > Paul de Vrieze <[EMAIL PROTECTED]> wrote: > > Adding profiles is technically broken. > > How? Requiring duplication of profiles for every package manager. Profiles determine what defaults are, and on some level what is installed. What useflags are supported, and some other things. Profiles do not determine how something is installed. A package manager determines how things are installed. As such any profile should work with the package manager. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp4coYwiME2R.pgp Description: PGP signature
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] Funding Request
On Thursday 18 May 2006 13:40, Simon Stelling wrote: > Hey all, > > To continue my development in an efficient way, I need a larger screen, > particularly one with a resolution of 1024x3972. However, I can not > afford the costs for such an investment, so I thought maybe the > community could help me out. > > The reason it has to be a screen with exactly the mentioned resolution > should become obvious after having a glance at: > > http://dev.gentoo.org/~blubb/funding.png > > Thanks in advance for your help, it is greatly appreciated! When I did not watch the image yet, I thought you had problems with the depth of the thread. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpy8CJ2jjOpf.pgp Description: PGP signature
Re: [gentoo-dev] Proposed package move
On Thursday 18 May 2006 13:24, Dan Meltzer wrote: > On 5/18/06, Paul de Vrieze <[EMAIL PROTECTED]> wrote: > > The package sys-apps/paludis is in the wrong category. It is a > > package manager on par with rpm, dpkg, etc. Those live in app-arch. > > > > Therefore I propose to move the paludis package to app-arch. > > > > It is not a system package at all. It does not even cooperate with > > system. > > > > Paul > > " > The app-arch category contains tools for archiving, compressing > and uncompressing files or groups of files. > " > > paladius does just as much archiving, compressing, and uncompressing > as portage... actually less without binpkg support. Maybe it's not a > sys-app, but it sure isn't an archive app. It does it as much as rpm and dpkg do. As I don't think it is a good idea to create a app-pkgmanager group I think it is best to put it with the other package managers in the tree. In any case it does not belong in sys-. It is not comparable with portage as it is an unsupported, third-party, package manager. Worst of all, conflicts with the official package manager. As anything in sys- is system and as such core to the distribution, I think that anything which does not cooperate with system, but even conflicts with it does not belong there. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpTAjgbsJ3Tx.pgp Description: PGP signature
Re: [gentoo-dev] New eclass db-use
Paul de Vrieze wrote: It has not been. As far as I know such a requirement does not exist. In It does. The reason for it is pretty good, as kloeri mentioned: The API of an eclass may never change. See GLEP 33 for some horror scenarios [1] ;) [1] http://www.gentoo.org/proj/en/glep/glep-0033.html -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New eclass db-use
On Thursday 18 May 2006 13:25, Bryan Ãstergaard wrote: > Was this discussed on gentoo-dev mailinglist before committing to the > tree? Eclasses are supposed to be discussed on -dev prior to adding > them to the tree to catch any (obvious) mistakes etc. > > This is particularly important for eclasses as they can't be removed or > changed in incompatible ways later due to the way portage handles them. > > I don't have time to look at it myself right now but I'd still > appreciate posting the code to gentoo-dev and have other devs/users > comment on it. It has not been. As far as I know such a requirement does not exist. In any case, this eclass only provides utility functions to find the proper location of berkeley db. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpZstvic3TD7.pgp Description: PGP signature
Re: [gentoo-dev] I'm retiring
Sorry to see you go Rob, you've done lots of good work. Good luck with everything. Tom -- Tom Knight [EMAIL PROTECTED] GPG Public Key: http://dev.gentoo.org/~tomk/tomk.asc pgpWykzXRVzKI.pgp Description: PGP signature
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
Request for a decision acknowledged. Fwding on mail to the rest of the council to ensure they see it. On Wed, 2006-05-17 at 17:38 -0400, Mark Loeser wrote: > As the latest long thread has shown, there seems to be a split (it is hard to > tell exactly) on whether or not alternative package managers, that support > Gentoo ebuilds to some degree, should be added to the tree and supported. > Supported in this case means having their own profiles which may or may not > work with Portage. There are currently a few different Portage rewrites, or > alternatives, whatever you want to call them, and all of them have their own > unique features being added to them which make them incompatible with Portage. > Some don't even emulate Portage's "broken" behaviour which could also cause > QA problems for us if we add the package to the tree. If a package is in the > tree, it is implicitly stating that we are going to offer some level of > support for that application, and it increases workload for everyone that > may have an ebuild that works with one package manager and not another. > > Therefore, I am requesting at the next Council meeting that they discuss > and decide on how we want to handle problems like this in general. This > is not going to be the last time that someone wants to add their rewrite/ > alternative of Portage to the tree. It should be decided if it is really > in the best interests of Gentoo, its users, and developers to be adding > these new managers to our own tree, instead of having them host their > altered work on their own infrastructure. > > As the QA lead, I am requesting that until the Council convenes and decides > on how we should proceed, that we not add anything else to the tree > for the sole reason of supporting another package manager's features. > This includes profiles or any other packages. This will reduce > headaches for all of us, and hopefully cut down on needless arguments > that get us no where. > > Thanks, > -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Funding Request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon Stelling wrote: > Hey all, > > To continue my development in an efficient way, I need a larger screen, > particularly one with a resolution of 1024x3972. However, I can not > afford the costs for such an investment, so I thought maybe the > community could help me out. > > The reason it has to be a screen with exactly the mentioned resolution > should become obvious after having a glance at: > > http://dev.gentoo.org/~blubb/funding.png > > Thanks in advance for your help, it is greatly appreciated! > Or you could try out the mutt ebuild that ferdy checked in earlier that is p.masked with the ignore-thread patch and save yourself, and anyone in the community some cash ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEbGnV1c+EtXTHkJcRApwjAKCAYvaQTEe/fFhVWYS1cHXNIVLpXACfT8Wd Nl7RDckneSDMnUdWcrzDqfk= =HCJe -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Funding Request
On Thursday 18 May 2006 12:40, Simon Stelling wrote: > Hey all, > > To continue my development in an efficient way, I need a larger screen, > particularly one with a resolution of 1024x3972. However, I can not > afford the costs for such an investment, so I thought maybe the > community could help me out. > > The reason it has to be a screen with exactly the mentioned resolution > should become obvious after having a glance at: > > http://dev.gentoo.org/~blubb/funding.png 0wned :) But seriously, I cannot give you funding as I don't think that your solution is all that future proof :P -- Roy Marples <[EMAIL PROTECTED]> Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Funding Request
On 5/18/06, Simon Stelling <[EMAIL PROTECTED]> wrote: Hey all, To continue my development in an efficient way, I need a larger screen, particularly one with a resolution of 1024x3972. However, I can not afford the costs for such an investment, so I thought maybe the community could help me out. The reason it has to be a screen with exactly the mentioned resolution should become obvious after having a glance at: http://dev.gentoo.org/~blubb/funding.png Thanks in advance for your help, it is greatly appreciated! Hehe - I needed a good laugh today :) Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Funding Request
Simon Stelling wrote: Hey all, To continue my development in an efficient way, I need a larger screen, particularly one with a resolution of 1024x3972. However, I can not afford the costs for such an investment, so I thought maybe the community could help me out. The reason it has to be a screen with exactly the mentioned resolution should become obvious after having a glance at: http://dev.gentoo.org/~blubb/funding.png Thanks in advance for your help, it is greatly appreciated! Classic :) -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On Thu, 18 May 2006 12:49:29 +0200 Paul de Vrieze <[EMAIL PROTECTED]> wrote: > Adding profiles is technically broken. How? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
On Thu, 18 May 2006 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] Funding Request
On Thu, 2006-05-18 at 13:40 +0200, Simon Stelling wrote: > http://dev.gentoo.org/~blubb/funding.png What a great way to start off my day.. Thanks hopefully I'll continue to laugh for the rest of the day. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] cmake.eclass
Hello,
Le Jeudi 18 Mai 2006 12:54, Simon Stelling a écrit :
> I have no clue what cmake is or what you are trying to, so I just
> comment on a few other things I catched:
Thanks for your comments,
Cmake is a autotools/autoconf replacement (http://www.cmake.org), it is the
new build system for kde.
Some projects using cmake need to have a separate builddir (kde does, and some
others).
In this eclass, there is an helper function to use cmake options according to
useflags (like use_enable), and the support for building out of the sources
(in $WORKDIR/cmake-build)
> [...]
>
> > cmake_compile() {
> > cmake_install() {
>
> aren't these meant to be cmake-src_compile/cmake-src_install?
Well, it is for cmake_install indead, but cmake_compile need that
cmake_configure has been done before... so I consider cmake_configure and
cmake_compile more like econf and emake commands.
So I've added a separate cmake_src_compile.
I've updated the eclass, according to your comments, and renamed cmake_install
to cmake_src_install.
I've also made the installation prefix customable with INSTALL_PREFIX envvar.
Here is an ebuild example for using this cmake eclass:
http://dev.inzenet.org/~panard/patches/gentoo-overlay/app-editors/yzis/yzis-0.1_pre20060518.ebuild
Thanks,
Panard
--
HomePage: http://dev.inzenet.org/~panard/
Yzis : http://www.yzis.org
Qomics : http://dev.inzenet.org/~panard/qomics
Smileys : http://smileys.inzenet.org
# Copyright 1999-2006 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#
# Original Author: panard
# Purpose: cmake with a separate builddir
#
ECLASS="cmake"
DEPEND="dev-util/cmake"
RDEPEND=""
IUSE="debug"
BUILDDIR="${WORKDIR}/cmake-build"
# cmake option helper:
# cmake_use_option [ [ []]]
# eg:
# USE=qt debug
# cmake_use_option qt => -DWITH_qt=ON
# cmake_use_option gtk => -DWITH_gtk=OFF
# cmake_use_option qt ENABLE_QUI => -DENABLE_QUI=ON
# cmake_use_option gtk ENABLE_GUI => -DENABLE_GUI=OFF
# cmake_use_option gtk ENABLE_NOGUI OFF => -DENABLE_NOGUI=ON
# cmake_use_option doc GENDOC full =>
# cmake_use_option html DOCFORMAT html text => -DGENDOC=text
# cmake_use_option debug CMAKE_BUILD_TYPE debugfull =>
-DCMAKE_BUILD_TYPE=debugfull
#
cmake_use_option() {
local USEFLAG="$1"
local OPTION="$2"
shift 2
OPTION=${OPTION:-"WITH_${USEFLAG}"}
local E_VALUE="ON" # value if use
local D_VALUE="OFF" # value if not used
if [ ! -z "$1" ]; then
case $1 in
[oO][nN])
;;
[oO][fF][fF])
# reverse values
E_VALUE="OFF"
D_VALUE="ON"
;;
*)
# non-boolean option
E_VALUE="$1"
D_VALUE="$2"
;;
esac
fi
local opt="-D${OPTION}="
if useq ${USEFLAG}; then
opt="${opt}${E_VALUE}"
elif [ ! -z "${D_VALUE}" ]; then
opt="${opt}${D_VALUE}"
else
opt=""
fi
echo ${opt}
}
cmake_configure() {
debug-print-function
debug-print "${FUNCNAME}: BUILDDIR is '${BUILDDIR}'"
INSTALL_PREFIX="${INSTALL_PREFIX:-/usr}"
mkdir -p ${BUILDDIR}
cd ${BUILDDIR}
echo cmake ${S} -DCMAKE_INSTALL_PREFIX=${INSTALL_PREFIX} \
$(cmake_use_option debug CMAKE_BUILD_TYPE debugfull) $*
cmake ${S} -DCMAKE_INSTALL_PREFIX=${INSTALL_PREFIX} \
$(cmake_use_option debug CMAKE_BUILD_TYPE debugfull) $*
ret=$?
cd ${OLDPWD}
return $ret
}
cmake_compile() {
cd ${BUILDDIR} || die "no BUILDDIR configured"
emake $*
ret=$?
cd ${OLDPWD}
return $ret
}
cmake_src_compile() {
cmake_configure $* || die "Configuration failed"
cmake_compile || die "Compilation failed"
}
cmake_src_install() {
cd ${BUILDDIR}
emake DESTDIR="${D}" $* install || die "Installation failed"
ret=$?
rm -rf ${BUILDDIR}
cd ${OLDPWD}
return $ret
}
EXPORT_FUNCTIONS src_compile src_install
pgpA49AijCUAk.pgp
Description: PGP signature
[gentoo-dev] Funding Request
Hey all, To continue my development in an efficient way, I need a larger screen, particularly one with a resolution of 1024x3972. However, I can not afford the costs for such an investment, so I thought maybe the community could help me out. The reason it has to be a screen with exactly the mentioned resolution should become obvious after having a glance at: http://dev.gentoo.org/~blubb/funding.png Thanks in advance for your help, it is greatly appreciated! -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New eclass db-use
On Thu, May 18, 2006 at 11:48:50AM +0200, Paul de Vrieze wrote:
>
> Hi all,
>
> I have just committed a new eclass to the tree. This eclass has as purpose
> to make it easier to use berkeley db. Currently the eclass has two
> interesting functions (and some helpers that may or may not be
> interesting).
>
> These functions are:
> db_includedir
> db_libname
>
> Both functions can be used with and without arguments. Without arguments
> they will give the best bdb version. With arguments they will loop
> through the arguments which are version prefixes (they will be matched
> with "=sys-libs/db-${1}*"
>
> The includedir function returns the include dir of the best matched db
> version. The libname function returns the libraryname of the best matched
> db. This libraryname has the form db-${ver}, and as such could be just
> appended to "-l". This means it is not the filename.
>
Was this discussed on gentoo-dev mailinglist before committing to the
tree? Eclasses are supposed to be discussed on -dev prior to adding them
to the tree to catch any (obvious) mistakes etc.
This is particularly important for eclasses as they can't be removed or
changed in incompatible ways later due to the way portage handles them.
I don't have time to look at it myself right now but I'd still
appreciate posting the code to gentoo-dev and have other devs/users
comment on it.
Regards,
Bryan Østergaard
--
gentoo-dev@gentoo.org mailing list
