But this would be a killer feature if Ubuntu can pull it off. I think there needs to be a fundamental difference in packaging philosophy to achieve this - for example the "-dev" being packaged separately will now need to go IMHO, etc.
But this would be a killer feature if Ubuntu can pull it off. I think there needs to be a fundamental difference in packaging philosophy to achieve this - for example the "-dev" being packaged separately will now need to go IMHO, etc.
This is an opinion - frequently development libraries, header files, etc. are dependent on kernel versions, glibc, etc. More so than binaries themselves. At the very least, a rolling release will change your kernel and glibc. Which means unless your header packages change in tandem, they might cause incompatibility problems.
It is less of a technical issue and more of a workflow one - would you want to handle the explosion of support requests similar to "I have mysql 5.1 but my PHP client does not connect to the DB.... oh crap, I forgot I have mysql 5.0 headers. heyyy, what gave you the right to upgrade my mysql ?"
If you go with the notion that disk space is cheap (and indeed packaging headers and dev libraries would be not too expensive in terms of disk space ), there is really no real reason to separate them both.
What you are suggesting would be near impossible to have happen without the user manually downloading deb packages, force installing using dpkg, and even then apt would shit itself over conflicting packages and broken dependencies. If someone manages to actually do that... well, they're going to have bigger problems than just "PHP isn't working right."
Rarely do packages need a particular kernel version, just ask anyone using xen or openvz where the kernel is often quite old (2.6.18) and not quite as easily upgradeable. The only time I've known of conflicts arising are when you need to use 3rd party binary drivers, or when an application is using bleeding edge kernel calls which is usually a bug upstream.
You may have a small point with glibc, but I imagine they'll just pin it to a major update every 3 to 6 months and give themselves time to test the heck out of it.
Lack of separate -dev packages is something I like very much about Arch because I build enough software that I'm happy to pay the storage cost for the headers in exchange for not having to track them down from the eventual compilation errors. It is entirely justified for a distro targeting a demographic that builds less, or with less available storage, to have separate -dev packages.