[haiku-development] Re: Package Management - devel or not to devel?
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 03 Sep 2013 21:32:29 +0200
On 09/03/2013 06:22 PM, Alexander von Gluck IV wrote:
On Tue, Sep 3, 2013 at 11:26 AM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
Maybe someone can give some details on the negative use case that makes
devel packages an "endless pain" and causes "untold hours of frustration". I
can't relate at all. All I have to do on Linux (openSUSE) is a "zypper
install foo-devel" to get foo's devel package (and foo itself, if it hadn't
been installed before). I don't recall ever having experienced any pain or
frustration doing that.
It's not that it is hard to install -devel packages.. however it is an extra
"little" step. All of these "little" annoyances end up being big issues in
the grand scope of things. By default, most libraries install the development
bits (when compiled from source). In essence, we are mutilating packages in
an effort to split them into -devel.
Most software's build systems install everything that has been built or
that belongs to the software by default. That often includes test
programs and other stuff that no one needs. By splitting the set of
files into different packages, we separate concerns -- so that stuff
that isn't needed for common use cases (like development files on end
user machines) doesn't have to be installed -- and we isolate
dependencies -- so that one doesn't have to install Qt, Java, Ruby, and
a web server just because the software comes with wrappers/bindings for
those.
Looking at the recipe's written so far,
the -devel packages manually move files out of the prefix path.
This causes
additional work for the package management team (which is already pretty small)
and provides little benefit to end users.
The prefix path is the installation location and nothing is moved out of
that. If you're referring to development libraries symlinks/files which
are moved from lib/ to devel/lib/, then this has nothing to do with the
devel package at all. The reason for doing that manually is that,
surprisingly, build systems generally don't seem to support a separation
of run time and development library files. The reason for doing that at
all is that with the switch to PM we chose to make the directory
hierarchy more consistent. We borrowed the structure of the (now gone)
/boot/develop directory that already existed in BeOS and added a
develop/ directory with a similar structure in each installation
location. This obsoletes the include/ directory that ported software
usually uses and requires development library files to be moved from
lib/ to develop/lib/.
Whether in hindsight this was a good idea, I'm not sure yet. From a
"swimming with the stream" POV it would have been a lot easier to just
go with include/ and lib/ as well. I find it a lot tidier now, though.
And on an end user system the develop/ directory simply won't exist,
which kind of makes sense.
It was mentioned that CD's are the same size and haven't changed much. While
this information is true, it really isn't a valid argument here. The majority
of the packages that would contain "excessive" development resources wouldn't
be on the installation CD.
Why is that? If you don't have separate devel packages, the development
resources -- excessive or not -- of any software will be included
automatically, if that software is included in the release. Looking at
my current gcc4h test image, the devel packages we currently include
"for good measure" weigh more than 31 MB. And there are more (like
subversion_devel (4.5 MB)) that we don't include.
Plus, given the compression hpkg includes, we likely
will be able to already fit a lot more on a CD.
Yes, we will fit more on the CD, but please keep in mind that the CD
included quite a few packages as zip files already, since they wouldn't
fit otherwise. We also include source archives and may want/need to
include more in the future.
On Tue, 3 Sep 2013 11:46:37 -0400
Ryan Leavengood <leavengood@xxxxxxxxx> wrote:
In the last few years, when I've used Linux I've mainly used Ubuntu
and Arch. I can't say I've had endless pain in trying to do
development in Ubuntu where there are development packages, but I will
say Arch was a breath of fresh air in NOT having them.
It might be more of a case of being easier and simpler in not having
the development packages than them causing a bunch of pain. Though for
poorly documented projects it can be quite frustrating trying to
figure out what is needed to compile and then having to install those
development packages, but it may be unfair to blame that on the
packaging system.
This is generally where I've seen pain. If you've compiled more than a few
pieces of software under any RPM based distro you've seen this. The minute
you step outside of the source RPM box, you're left in a cycle of:
- running ./configure
- install missing package X-devel
- running ./configure
- install missing package Y-devel
- running ./configure
- install missing package Z-devel
- etc
Do that for more than a few source archives in a row and you will be in the
no-devel camp pretty quickly :-)
If you run into this often, I would recommend 1. reading the
README/INSTALL files, 2. running "./configure --help" to see what
options exist for required and optional dependencies (usually some
"--with-foo"), 3. check your favorite Linux distro's build recipe for
that software.
If Haiku can do it "right", it might not be so bad.
- I agree, however do we have the resources to do -devel "right"?
I don't know about "right". What I can say is that not doing separate
devel packages will not be automatically less work for the packagers.
It's probably even more work for them and it makes the whole system more
fragile.
As you know most build systems automatically discover required and
optional dependencies and make use of them, when available. While this
is generally nice, it is a big problem for packaging, since pulling in
dependencies the packager isn't aware of leads to packages that lack
dependency declarations, which in the end will be a problem for the user.
We've gone to great lengths to prevent this from happening: haikuporter
builds ports in a chroot environment that only contains the packages
that have been explicitly specified in the build recipe (plus their
dependencies). This helps a lot, but the used build tools will also pull
in library packages they depend on. If we didn't have separate devel
packages, those libraries could be picked up automatically by the build
system, since the headers and development libraries would be available
as well.
A typical example is gettext. It is automatically found by most build
systems and the built libraries and executables then use its libintl.
Once you have a grep, sed, gcc,... depending on libintl, you'd have a
hard time of trying to build software such that it doesn't depend on it.
I do agree with Rene that disk space is no longer virtually infinite
with SSDs, so there is no reason to be unnecessarily wasteful.
With all this said, I could envision there being a setting for the
package management system which always installs the -devel packages
when the main package is installed (assuming the -devel package
exists.)
I guess that would be OK.
This then can satisfy both camps without being a bad
compromise. For that reason (and just for clarity), it might be nice
if -devel packages were linked with their associated main package more
tightly than just naming, such as each having a reference to the
other. I don't know if this is already there.
No, not yet.
CU, Ingo
Other related posts:
