Code: Select all

As I think, the package maintainer intends to make
'neon' the 'default' vendor (Vide: 'man dpkg-vendor').
But this does not work. It's still 'ubuntu'.


Let's investigate:
==================


1. Step: (Some of) The FilesystemObjects installed by package 'base-files'
==========================================================================

$ dpkg -L base-files | command grep '/etc/dpkg/origins'
/etc/dpkg/origins
/etc/dpkg/origins/neon     #    'neon'    is installed by file copying
/etc/dpkg/origins/debian   #    'debian'  is installed by file copying
/etc/dpkg/origins/ubuntu   #    'ubuntu'  is installed by file copying
                           # no 'default' is installed by file copying



2. Step: The 'if'-Compound Command within the post-installation script
======================================================================

# Creation of the '/etc/dpkg/origins/default' SymbolicLink file:

$ command grep -A 4 '^if \[ ! -e /etc/dpkg/origins/default \];' /var/lib/dpkg/info/base-files.postinst
if [ ! -e /etc/dpkg/origins/default ]; then  # Why only if it does NOT exist? Delete this 'if'!
  if [ -e /etc/dpkg/origins/neon ]; then     # <== O.K. Keep it.
    ln -sf neon /etc/dpkg/origins/default    # <== O.K. … But make it '/etc/dpkg/origins/neon'.
  fi                                         # <== O.K. Keep it.
fi                                           # <== DELETE IT.


Let's translate this into plain English:

ONLY IF

    the FilesystemObject '/etc/dpkg/origins/default' doesN'T exist # <== makes no sense

  AND

    the FilesystemObject '/etc/dpkg/origins/neon'    DOES    exist

THEN

  delete any preexisting '/etc/dpkg/origins/default' and
  create a new SymbolicLink, named '/etc/dpkg/origins/default'
                              and
                             pointing to 'neon' # Why not '/etc/dpkg/origins/neon'?



# Now, after installing 'base-files' (copying files + running script):

3. Where does the SymbolicLink ('ln -s') point to on my KDE Neon installation?
==============================================================================

$ command ls -l /etc/dpkg/origins
total 4
-rw-r--r-- 1 root root 1 Feb  3  2009 debian
lrwxrwxrwx 1 root root 1 Sep  1 23:35 default -> ubuntu  # _N_O_T_ 'neon'!
-rw-r--r-- 1 root root 1 Aug 15 16:40 neon
-rw-r--r-- 1 root root 1 Okt 22  2015 ubuntu


4. Suggested Solution:
======================

A) Permanent Solution (for package maintainer)

Fix postinst script:
a) Delete outer 'if'
b) Replace 'neon' by '/etc/dpkg/origins/neon'


B) QickFix (for users)

sudo ln -sf /etc/dpkg/origins/neon /etc/dpkg/origins/default


*** THE END ***


Did I make any mistakes?

Comments, please!


Well, fortunately I can retract part of my critique regarding the postinst script.

This was perfectly fine and correct:

ln -sf neon /etc/dpkg/origins/default


But, nonetheless:

$ dpkg-vendor --query vendor
Ubuntu

still doesn't seem the right/intended/expected result.

Therefore, I think the rest remains problematic. So, what is the right solution?

Is 'Ubuntu' right, even if the 'neon'-variant is configured-in
but not used (intentionally/erroneously)?

Probably even if the vendor remains ubuntu, the neon package (from the PPA) should override it because of the package version numbering being "higher" with all bits appended to it. Just that the version happened to not override (compared higher) when 16.04.2 official package version came in?

If you see the ubuntu package versions, they were "9.4ubuntu4.3" then "9.4ubuntu4.4" but neon was "9.4ubuntu4.3+p16.04+git20170112.1812", now it is "9.4ubuntu4.4+p16.04+git20170210.1607"

So, in case ubuntu again bumps to "9.4ubuntu4.5" it will again mess with neon unless the devs bump the neon package version beforehand

Probably neon should have better package version - not sure how the comparison to decide which is higher is done - maybe a string compare?

I, too, am concerned about the version numbering scheme in KDE Neon.

Another possible can of worms may be version-pinning in the
'/etc/apt/preferences.d' files.
For example:

Code: Select all

$ grep -E '^[^ ]+'  /var/lib/apt/lists/archive.neon.kde.org_user_dists_xenial_InReleas
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash         : SHA256
    Origin       : neon                                            # Pin: release o=neon
    Label        : KDE neon - User Edition          # Pin: release l=KDE neon - User Edition
    Suite        : xenial                                           # Pin: release a=xenial
    Codename     : xenial                                   # Pin: release n=xenial


I really don't know: Is it a good idea of KDE Neon to call their 'Suite' and 'Codename'
the same as Canonical/Ubuntu call their's?