Re: Building native packages with pkgsrc

["Mikhail T." <mi+r29b%aldan.algebra.com@localhost>]

On 10.08.2017 22:24, Johnny C. Lam wrote:

Supporting additional package formats is currently being worked on, but with no timetable for completion at present.

I'd like to inquire about the status of Ubuntu/Debian packaging in particular. Is that in the state, where a reasonably competent person can start building native packages?

However, the statement that "there is no justification" for using our own binary package format and tools is overly dramatic.

I'm sorry for appearing "dramatic" -- assuming that's a bad thing in the first place. But I remain of the opinion. The difficulties you list may be real, but they need overcoming -- the attitude of "screw them, we'll use our own" is, in my not so humble opinion, what's holding pkgsrc from achieving the adoption it richly deserves.

There are most definitely _reasonable_ justifications for it; three reasons come to mind rather quickly:

* Not every binary package format has features that map cleanly onto
  other package formats.

I don't see, how this is important or even relevant -- you don't need to translate between package-formats. You just need to create native packages, whatever they are...

* Not every package manager interprets or compares version strings
  in the same way.

True (and I did struggle with Solaris on this only a few years ago), but you don't need multiple package-managers to coexist -- as long as the same OS is using the same packaging, the behavior will be consistent.

* Not every system follows the same file and directory layout.

Yes, this is correct -- and your current way to escape this is to simply install under a PREFIX of your own. However, most software does its own installation with guidance from the package-builder (--prefix, --exec-prefix, etc.) This guidance can be different on different OSes and the efforts to maintain it is comparable to the efforts sunk into maintaining pkg_* utilities, that compete with the native package-managers...

to be actively tested and maintained to avoid bitrot.

That's always a concern, is not it? Some OSes will have more bitrot than others -- the same way hardware architectures already differ in the level of NetBSD support -- that's life. But that's not a reason to continue down the road of competing with the native OS tools, is it?

Though I understand, that package managers vary much wider than C-compilers, they should still be considered a local tool (like cc or ld) -- with work-arounds for particular idiosyncrasies, but without attempts at complete replacement.

Yours,

-mi