Compatability with FreeBSD Ports [debian package tools]

[Hiten Pandya]

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 at xxxxxxxxxxxxx