tech-pkg archive

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

Re: multiple version of packages with the same PKGBASE

> So, essentially I'm arguing that many cases that require this
> SUPERSEDES logic should not have happened - my standard plea against
> renaming, which will continue even if we have good mechanisms.

Ending package names with version like glib2, emacs22 etc. is the
approach to reduce a number of renamings. That's right. But renamings,
splitting etc. will always happen. For example, I don't think that
keeping both bzip2 executable and libbzip2 in a single package is good
approach. And I hope some day they will be splitted. So, why not to
provide a way to correctly handle such situations. Using pkg_summary
and SUPERSEDES with version regions is a simple way to do this without
extra bloat you all love so much :)

At work I use Debian/Linux where upgrades are done smoothly in most
situations. I don't see any reason why pkgsrc cannot do the same.  I
think it can, keeping, at the time, their own advantages - it is
source-based, portable, has no stupid extrastrict dependancies (on
glibc version for example), it has no bad conflicts (under Debian I
cannot install exim and ssmtp for example).

P.S.  There is another reason why it is better to implement SUPERSEDE
functionality. In Linux world it is common plactice to separate
library packages (.so.x.y.z and .a) from -devel packages (.h and .so).
They also often separate -doc packages containing .pdf, .ps etc. Also
in many distributions packages are very small and have very limited
functionality, i.e. big software is separated into a number of
relatively small packages (Debian, Alt Linux). I personally think that
this is a right direction of developing a packaging system.

In pkgsrc I see another approach, probably because it has no
"subpackages" (category/pkgname -> pkg1, pkg2, ...).

Imagine (just imagine! :-) ), that pkgsrc developers decide to do the
same things. In this case you'll need to make tons of "splittings"
including bzip2 -> bzip2/libbzip2 of course. All this can EASILY be
done and upgrade will be smooth. Why not?

Best regards, Aleksey Cheusov.

Home | Main Index | Thread Index | Old Index