On Wed, Feb 16, 2005 at 02:17:24AM +0100, Marius Mauch wrote: > > My question is - why not? > Personal opinion: This splitting (and all the other subpackaging) is one > of the main reasons why I don't use redhat (or other binary distros) > anymore. I can see the use (so don't try to convince me with examples), > but personally I hate it. If we would go on and change the main tree to > split packages this way I'd probably leave Gentoo too (this isn't meant > as a threat in any way). Don't know how other people feel about this. On most of my machines, I see absolutely no need for split packages, but for purpose-specific enterprise servers and embedded machines, I see a valid reason for trimming the system.
The point I'm aiming for is being able to create binary sub-packages to
deploy in specific locations. I do not want to change the normal
built-from-source system.
I didn't like RH's splitting either, but if you look at their SPEC
files, there is actually NO requirement to make your RPM have
sub-packages. The original RPM format didn't even have it, and it was
later added as an extension.
Could you explain why you hate the existing sub-packaging of other
distros?
> > I have an idea about how we could go about implementing this. Rather
> > than adding (f.ex) a libjpeg-devel package, we could enhance Portage
> > to support a second image directory. Ebuilds could then put runtime
> > files into ${D} as normal, and 'devel' files into (f.ex) ${I} (it's a
> > shame that ${D} was chosen for the image directory ;-)
> And then what? You have the files separated in the sandbox, but how are
> you going to use that? Generate two binary packages, only merge the
> devel stuff with FEATURES=devel-files, ...?
What I'd ideally like is to compile once (absolutely no change to
src_compile of ebuilds) and package once, but have extra data in the
binpkg metadata, showing what files belong to what sub-package.
(optionally later spit out multiple binpkgs, one per sub-package).
> For the latter there is
> already INSTALL_MASK to avoid installing unwanted files (new feature).
> For the first I don't really see the use unless you also change the
> dependency system.
> Btw you don't really need to put the logic in the ebuilds, development
> stuff can nearly always be matched with a simple find command (headers,
> static libs.
As I noted in my original response, custom sub-packages hold definite
benefit in some specific cases.
INSTALL_MASK is clumsy for selecting files, and it isn't kept between
emerges from what I can see (much like calling ACCEPT_KEYWORDS="~x86"
emerge foo).
I don't exactly like Stuart's idea on implementing it, and I have my own
idea for it as well.
Basic concept:
- src_compile entirely stock.
- src_install entirely stock and still goes to ${D}.
- new phase that describes which sub-package stuff belongs to.
Ideas on defaults for the new phase:
In the form of a code snippet.
subpkg_select() - this controls what subpackage we are defining.
subpkg_from() - grab all FILES in $D that match this globbing pattern,
and assign to currently selected sub-package. -R for recursive.
Directories are NOT matched. Each assignment for a file overrides the previous
one.
Code for smart defaults:
generic_pkg_subpkgbuild() {
# special sub-package name for the base sub-package
subpkg_select _base
subpkg_select -R /
# if we wanted binaries separately, no advantage I think
#subpkg_select bin
#subpkg_from -R {/usr,}/{,s}bin/
#subpkg_from -R {/usr,}/{lib,lib32,lib64}/
subpkg_select devel
subpkg_from {/usr,}/{lib,lib32,lib64}/*.a
subpkg_into -R /usr/include/
subpkg_select doc
subpkg_from -R /usr/share/{doc,man,info}/
}
Then each ebuild can override or extend this as needed. I'd estimate
that at least 60% of our ebuilds can just take the above defaults, with
absolutely no work on the part of their maintainer.
On the extraction side, portage sees which sub-package(s) are requested
(how this is specified is undefined at this point), and only installs
those after extracting. As the default, none are specified, then install
the entire binpkg (all subpackages).
I agree that there will be some difficult work in getting this to mesh
with the dependency system, but it would still not be impossible.
As a show of support, I'm willing to work on coding the above into
Portage.
--
Robin Hugh Johnson
E-Mail : [EMAIL PROTECTED]
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpi1W2B715ci.pgp
Description: PGP signature
