[haiku-development] Re: Package Management - devel or not to devel?
- From: Isak Andersson <contact@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 3 Sep 2013 21:41:11 +0200
While we are at it, shouldn't we split it all in to -doc, -debug (for
tools), etc :P. I mean it *would* save space after all.
Cheers
Isak Andersson
contact@xxxxxxxxxxxxx
On 9/3/13, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> 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:
