Re: Package management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



I think that it would be completely up to the Arch developers and to each
user. If there's only one application that depends on an outdated version
of a library, that application should be patched to work with the newer
version. If it's a very big program (say, X), however, or if there are lots
of applications depending upon the old version (the Python2 case), then it
would be justified to maintain both.

Note, however, that the model I propose wouldn't introduce many changes.
The python2 package, for instance, would be called simply "python" but have
version "2.x.y"; but no more job would be required, since python2 and
python packages can already coexist.

I have to think more about "alternatives". Instead of the script I proposed
earlier, it could be a pacman built-in feature, that simply created
symbolic links. As every package would have binaries and libraries
versioned, symlinking would be needed to avoid having to use "cp-8.9.4" and
the like. If pacman finds itself installing a package for the first time,
it should create symlinks automatically; if there's already a package with
the same name installed (and with symlinks created), it should just warn
that "${pkgname} defaults to ${version-already-set-as-default}".

Functionality for alternatives management could be implemented with the
"-A" switch:
$ pacman -A python=2.7.3
ln -sf /usr/bin/python2.7.3 /usr/bin/python
(A possible problem would be UEFI setups in which kernel images reside on
the ESP; FAT does not support symbolic links. Maybe copies could be used as
a fallback.)

There are also directories in /usr/lib that should be renamed. For example,
/usr/lib/{systemd,kmscon,chromium}. Configuration in /etc could be other
problem (I wouldn't like seeing /etc/X11-15.1.0).

Please note that outdated versions would NOT be held in official
repositories. However, as official PKGBUILDs are in an SVN tree, an user
could checkout the desired version and build it for himself/herself (if I
have understood it correctly).

Regards,
Kalrish
On Jan 6, 2014 1:54 AM, "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
wrote:

> On 01/05/2014 08:07 AM, Kalrish Bäakjen wrote:
> > These were all the ideas. If you haven't understood something, please
> > ask. Thanks,
> > Kalrish
>
> All are good ideas, but I think they work against simplicity that Arch
> tries to
> maintain. In several cases there are multiple library versions available
> out of
> necessity. libpng, libpng12, etc... I understand what you are proposing,
> but I
> have a feeling it would be manpower prohibitive to do on any larger scale
> than
> what is presently done.
>
> The question I have is "What is the criteria that would determine which
> packages
> need/get multiple versions?"
>
> --
> David C. Rankin, J.D.,P.E.
>


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux