Bob Sanders wrote:
>>From what I understand of Gentoo, it basically downloads the equivalent
>>of an SRPM and builds it then installs the binary.
>>
> 
> 
>>From Levi's and others comments, everyone seems to have missed the real 
> differences in the methods.
> 
> (S)RPMs carry meta data with each RPM.  With Gentoo, the meta data - how
> to compile/make the file and it's dependencies are external to the source,
> in a portage database/storage area -/usr/portage/.
> 
> With an (S)RPM, to fix a build problem, the script must
> be changed, the RPM re-built, then tested.
> 
> With Gentoo, the script is changed, then tested - it's not necessary to
> rebuild before test as the build is the test because the script is
> external to the source, an ebuild script in the portage data directory.
> 

Sorry, I don't follow, you don't 'change' a 'script' without building
the rpm. So, Gentoo keeps it's meta-data somewhere, well, so does
Mandrake, in Mandrake CVS. All you need to do to build any
(well-maintained, all the patches being in cvs etc) rpm is:
1)Check out the packaging from Mandrake CVS
2)Get the original source
3)rpm -ba path/to/mandrake/cvs/package/package.spec

Then you just need to install the package to test the pre/post scripts.
There is no way around this if you are duistributing binaries (this may
be the issue you are referring to?, you aren't clear).

> With both RPM and Portage any source code change requires re-packaging the
> source code into a tar-gz/bz2, so no advantage there.

Not necessarily, RH uses tar.gz, Mandrake just uses bz2 to save space,
but that is what bzme is for.

> 
> Another real difference that some find an advantage is the ability to
> update the portage database without doing any actual install.  Indeed,
> a build can occur without ever affecting the running system because all
> builds occur in a sandbox environment.

That's how rpm works on any decent distro ... you only need to install
to test the software itself and the pre/post scripts.

[...]

>>It shouldn't be that difficult in theory to hack urpmi to support that
>>(providing that a source-equivalent for hdlists and so forth is
>>created).  If Mandrake integrates both automatic compilation of desired
>>packages with the ability to download binaries, that would be a killer
>>feature, imho.
>>
> 
> 
> The problem is not urpmi, nor is it the ability to auto-compile packages.  Doing
> such would not solve the inherent problems with RPM.  Mandrake is a great
> distribution, but it weighed down by RPM.  And that is the real issue and
> problem - meta data contained with the individual application/program when
> numerous dependencies on other apps/libs and a one-way install method.

Sorry, you're going to have to be more clear with your issues with rpm.
I don't see any issues with rpm that aren't solved by urpmi, or present
in something like dpks (remember not to compare apt and rpm, you can't).


> There are times when it is necessary to run multiple versions of libc or glibc, etc.
> There will be more of these in the future when running 32-bit and 64-bit on the
> same platform.  The package management system is going to have to deal with this
> in a fairly robust fashion and from what I've seen, I'm not convinced RPM can
> do that or that I want to put up with the workarounds it will require.

Sure, gentoo's idea (slots?) doesn't have an equivalent in rpm, but I
don't see that it's an earth-shattering problem. Just make alternative
package names (such as samba3-server etc).

> Can Gentoo have a gui'fied automatic install of binaries?  Sure.  It's just another
> set of work to do.  Should it?  It's not my call.  But that's not the real issue.
> Should Mandrake drop RPM?  Now that's the real issue.

Well, after you've weighed up the advantages of changing from rpm to the
amont of work it would be to port all the spec files to something else,
and the lost value in having cvs history on those spec files, then I
think you may consider it would be better to fix rpm.

Buchan

-- 
|--------------Another happy Mandrake Club member--------------|
Buchan Milne                Mechanical Engineer, Network Manager
Cellphone * Work            +27 82 472 2231 * +27 21 8828820x121
Stellenbosch Automotive Engineering         http://www.cae.co.za
GPG Key                   http://ranger.dnsalias.com/bgmilne.asc
1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7


Reply via email to