Compatability with FreeBSD Ports [debian package tools]
hmp at backplane.com
Wed Aug 17 18:28:19 PDT 2005
Jon Dama wrote:
This is hardly the point is it? Its true enough that one could easily
view supporting DragonflyBSD as if it was just another major version
number of FreeBSD--even if the mechanisms are very ad-hoc.
Hmm, very debatable and delicate issue, I will leave answering this one
because it can get quite sticky, if you know what I mean. :-)
The question here is that there are a handful of us and we want to
piggy-back off a much larger development community. So it isn't just a
question of whether individual port maintainers are willing accept
comptability patches but whether the ports team is willing to accept
compat patches against things like bsd.port.mk that minimize the hackery
necessary on an individual port basis.
Well, to be honest with you Jon, I certainly haven't tried sending "compat
patches" to Kris or any of the senior ports people so I am not going to
judge on that basis. If someone has tried this and got denied, please
speak up; this is a tangent by the way. :-)
There are at least a _few_ exceptions to this. One being mplayer where
you can get a few percent improvement allowing it to taylor itself to your
CPU at compile time. Don't scoff though, this can make the difference
between acceptable and intolerable dvd playback.
Of course, but if the consequence of changing such a build option is that
dire, than the package builders should supply an optimised version as
well; this would hardly be any effort. For those who want to argue
semantics, I am not saying we would want to do that for each package.
Another critical exception is certain setuid applications such suphp (a
special form of suexec). Certain security rules are set at compile time,
but I can assure you this is not an extreme situation. Now perhaps the
author of said program should have enabled more runtime configuration but
given the nature the program, I find this arrangement more
comforting--especially since I can set immutable flags on the resulting
I am not opposing building of very large applications; certainly do so if
you have the time and patience but it is hardly the deciding factor to
destroy the overall image of having a better supported binary package
The average guy who wants to get a system up and running from a Live-CD
and then install things like GUI, editors, will not really care about
source level "broohah" at all.
Lets be honest with ourselves, most of us do not bother with source level
building of packages that are available in binary form. If I really did
not trust an application, I would build from source, but this does not
describe 90% of the people out there.
If one really DOES NOT have assurance and piece of mind in the package he
is going to use, then
I whole heartedly agree though about KDE or OpenOffice.
Can we not use ports or pkgsrc as our build part of the problem, and
produce packages that are understandable by APT* ?
I completely agree that something of this form is desirable. Whoever
earlier commented that the build setup and the package management were two
problems not one was quite right. That said, it is a very desirable
feature of FreeBSD Ports/Pkgs that you can easily mix installing some from
binary packages and building some as ports.
The point is sometimes offering extreme level of flexibility also back fires.
Custom built packages SHOULD NOT be registered with the rest because this
will definitely not help while upgrading or during maintenance. They
marked as custom built and left alone, if necessary otherwise the chance
of screwing up the system just increased.
Source level upgrades have always created some form of problem for me and
it seems a lot of other people as well. Definitely not something that is
viable or trust-worthy.
It would be equally nice if it was easy to register installations that are
not performed directly using the packaging system.
It would be nice to flag custom build packages as separate, so upgrades of
them and their dependancies do not get hosed. I know that is not asking
for too much.
To summarise, at this point in time, I do not really give a crap for
building applications from source when a perfectly working binary package
is being offered. It should be the responsibility of the package builders
to take care of source building for us, not the end user. Period.
As for the differences between ports and pkgsrc, they are very, very
semantical in nature. The VIEWS support really should be the deciding
factor for selecting the said system, i.e. pkgsrc.
hmp at xxxxxxxxxxxxx
More information about the Users