T.J. Duchene wrote:
> > The reasoning is very simple. APT does not provide the mechanisms to
> ensure >that things like systemd do not happen again.
>
> Admittedly, I should have been clearer. The reason I think that APT should
> eventually be forked is that:

> a) Extremely important: It does not provide a clear rollback mechanism for
> package files to previous versions of binary packages.
> b) Related to user choice. It does not provide package methods for
> multiple versions of init or other system utilities that might exist.
> c) It does not provide for multiple versions of binary files to be
> installed on a system in a coherent manner, say two versions of Perl.
> d) Less important but still a consideration is that it does not provide a
> method for delta files.

Hi,

You realize, of course, that Devuan developers are going to
be up to their eyeballs to build up an infrastructure
even *without* major changes to the underlying systems.

Now to your criticisms of APT.

For perl, this is not particularly an issue, since perlbrew[1]
allows the user to have multiple versions of
perl installed in her $HOME directory.

APT is rather core to Debian, and unlikely, IMO to be
rearchitected. AFAIK, source distros such as gentoo and CRUX
do not allow this flexibility either.

One distro package system that *does* support (a,b,c) is Gobo
Linux. Gobo uses the filesystem instead of a package
database. Gobo installs each compiled app in its own
directory, with symlinks to bring files to commonly expected
locations such as /usr/bin and /usr/lib, /usr/include, etc.
That it was proposed and implemented so many years ago, and
few other distros have picked it up is testament to inertia
in the major distros.

If you compare the package data for Thunar file manager
under Ports[2,3,4] and under Gobo[5,6,7,8]

* A Gobo recipe[5] is similar to a Ports Pkgfile[2]
* Gobo doesn't require a manifest whereas Ports does[3]
* Ports doesn't provide dependencies information
* Gobo packaging declares build and runtime dependencies
* Gobo provides an explicit description of the package

> And that is just the most obvious thoughts. I could probably come up with
> a handful more given time. I would expect that if we succeeded in adding
> these and other features that Debian might merge them back into APT, should
> their egos allow it.
>
> I'm not going to crusade and argue for why APT really needs change. That's
> for some other time. I'm just saying that I've seen better resolution
> heuristics and feature sets elsewhere.

You gave a list of problems with APT, so that more or less
covers it.

I'm curious which package managers you think highly of.

> Personally, I think APT should undergo a process of gradual replacement,
> and before anyone comments that that would mean a complete break with
> Debian, I would humbly disagree. Debian has conversion tools for RPM to
> DEB, for example. There is no reason that if we did decide to break away
> from Debian, that we would have to completely jump ship.
>
> Frankly, it is my opinion that even if Devuan takes off, in about 2
> releases or about 5-6 years, keeping regular package compatibility with
> Debian will be impossible anyway. If Debian stays on the systemd path,
> Devuan will have to completely rebuild and repackage every single piece of
> software that even touches startup. Contrary to what people keep saying,
> there are subtle but distinct scripting differences between System 5 and
> Systemd.
>
> Systemd is NOT a drop in replacement, nor does it allow for 100%
> compatibility with System 5 startup scripting.

If Devuan takes off, there will likely be labor available
to maintain initscripts, which don't usually change all that
radically over time. My understanding is that systemd will replace
init scripts with their own unique declarative files.
No one will be re-writing init scripts for systemd.

Cheers


1. http://perlbrew.pl/

2. http://crux.nu/ports/crux-3.1/xfce/thunar/Pkgfile
3. http://crux.nu/ports/crux-3.1/xfce/thunar/.footprint
4. http://crux.nu/ports/crux-3.1/xfce/thunar/.md5sum

5. http://svn.gobolinux.org/recipes/revisions/Thunar/1.4.0-r2/Recipe
6. http://svn.gobolinux.org/recipes/revisions/Thunar/1.4.0-r2/Resources/BuildDependencies
7. http://svn.gobolinux.org/recipes/revisions/Thunar/1.4.0-r2/Resources/Dependencies
8. http://svn.gobolinux.org/recipes/revisions/Thunar/1.4.0-r2/Resources/Description
> ___________________
--
Joel Roth