[OpenIndiana-discuss] Do you ever think about adopting APT+DPKG?

[aurelien.larcher at gmail.com]

Le Mardi 2 mars 2021, Chris a écrit :
> On 2021-03-02 09:56, Judah Richardson wrote:
> > On Tue, Mar 2, 2021 at 11:43 AM Chris <oidev at sunos.info> wrote:
> > 
> >> On 2021-03-01 06:33, cretin1997 via openindiana-discuss wrote:
> >> > We have the tech there. Well adapted for our needs. APT+DPKG based
> >> Illumos
> >> > distro
> >> > is not unpopular. Some distros even use RPM.
> >> >
> >> > Most historic APT+DPKG based distros already dead, only DilOS is left
> >> now.
> >> > So we
> >> > could have a look at DilOS, the way they patched and utilizing APT+DPKG
> >> and
> >> > we can
> >> > even co-operate with them, if both side wanted.
> >> >
> >> > We already see too many problems of the IPS pkg. Could we switch to
> >> another
> >> > path?
> >> >
> >> > I know compatibility haunted us. But recently we broke it already. It's
> >> no
> >> > longer
> >> > the holy grail we have to keep at all cost anymore.
> >> >
> >> > Could we patch our oi-userland to generate DEB packages alongside of IPS
> >> > packages?
> >> >
> >> > The DilOS people has figured out how to build illumos-gate into DEB
> >> packages
> >> > already.
> >> >
> >> > This will not as hard as doing from scratch as we have many references.
> >> There are many possible "package managers" available. Some have already
> >> been
> >> recobbled
> >> to support Solaris derivatives. But IMHO the DEB package managers are not
> >> as
> >> efficient
> >> 
> > I'd say this is largely an academic argument. I have 3 machines that use
> > apt + deb with no associated issues. Actually, # apt dist-upgrade on Debian
> > Buster, Ubuntu 20.10, and Raspberry Pi OS Buster runs MUCH faster than #
> > pkg update -v -r on OI Hipster with approximately the same underlying
> > hardware (Intel Core 2nd Gen, 16 GB RAM) for the OI, Debian, and Ubuntu
> > machines.
> > 
> > as many of the others, it's a real "cache thrasher".
> > 
> > I don't think this is an issue if you have a decent (e.g. Samsung 860 Evo
> > or better) SSD with good endurance specs.
> Agreed. It's also not an issue with more RAM/cores && higher frequencies. ;-)
> 
> In the end, I don't really care _which_ package manager is chosen; as long
> as there is only _one_ and that it's the simplest to use for the package 
> *creators* :-)
> Ultimately; that should ensure the most packages for the users, with the 
> greatest
> package integrity. No? :-)
> 
> --Chris
> > 
> > Many of the others are
> >> more DB
> >> centric. Which tends to make them much faster and less resource abusive.

The other ones do not use a SAT solver that cross checks any action on the system...

Also I have repeated this a lot of times on the past but here again: traditional archive-based package managers are very slow for large updates.
APT in particular is awful for a large number of packages triggering postinstall scripts.

I think there are a lot of misconceptions about the boundaries of IPS.
If it were just solving dependencies and unpacking tarballs and triggering shell scripts if would be as fast as the rest...

Now if the discussion is whether the design has rough edges or whether the incurred penalty is worth paying for a desktop system where you do not care much about consistency... it is another topic. 

> >> 
> 
> -- 
> ~10yrs a FreeBSD maintainer of ~160 ports
> ~40yrs of UNIX
> 
> _______________________________________________
> openindiana-discuss mailing list
> openindiana-discuss at openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>