DragonFly BSD
DragonFly users List (threaded) for 2005-08
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Compatability with FreeBSD Ports [debian package tools]


To: Jon Dama <jd@xxxxxxxxxxxxxxxx>
From: Hiten Pandya <hmp@xxxxxxxxxxxxx>
Date: Thu, 18 Aug 2005 02:28:19 +0100

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 binary.

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 management solution.


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.

				Hiten Pandya
				hmp@xxxxxxxxxxxxx



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