The ports-system and userland in general.

[Weapon of Mass Deduction]

Magnus Eriksson wrote:
On Thu, 16 Dec 2004, Weapon of Mass Deduction wrote:

Magnus Eriksson wrote:
 Please think of a system that does not depend on magic Makefiles.  Make
a specification that anyone can implement, be it with 'make install' like
command-line tools, graphical package selection or whatever.  Just leave
room for smart implementations you haven't thought of yet.


I am certainly thinking about that too. However, much software today
comes with those nasty makefiles, sadly...
Though we could of course replace their functionality. But that might
be a bit too ambitious in this stage. ;)


 Separate out building packages from package management, if at all
possible.  You should be able to walk the dependency tree (and configure
packages) before anything gets written to disk.


I do not understand what you exactly mean by this. In which way you
would say the building process interferes package management or vice
versa, or in which way is it cluttered with the package management or
vice versa?
  I'm not sure I understand what you wrote either.  :-)
Hehe. Well, I just strive to formulate exactly. But I should try to write
more clear also. ;)
  But basically what I meant in those two paragraphs is that package
management should be completely separate from package building.  I.e, the
same basic system should work for both binary and source packages;
fetching a binary package should be logically equivalent to fetching and
compiling a source package; and handling dependencies, installing packages
should be separate from the fetching / compiling step.  (Put another way,
please, please, please, no recursive makes.)
 I guess this is where someone will tell me why it can't be done.
Apparently that might be likely, but I think it is not.

My point of view in pseudo-code:
Complexity != impossibility
!Feasibility, ...  ---> impossibility
(Just to not spend too much words... :D)

However, my question to you was: why would this be a problem for pkgrsc 
and its likes? Some issues you describe are - indeed - applicable to 
pkgsrc etc., but how do you mean building is interfering with the
package management in the current situation? I mean I am not under
the impression that is true, though I might be wrong of course.

  In the first paragraph, I don't mean that we should try to have our own
replacement for Makefiles for building from source, that would be stupid.
Well, if you put it that simple, I couldn't agree with you more.

 For binary packages: Always have a minimal build, as well a typical
build ("Surely, *everyone* wants OpenGL support in their xmms...").
 For "some compiling required" packages: Have minimal and typical
configurations that can be selected, as well as letting the user
customize.  And list options relevant for the package!  (with/out X11,
Truetype ...)  I'm thinking maybe checkboxes?


Well, that could a be realized with pkgsrc and its likes. But, as I
already wrote in my posting before this one, it is merely a problem
of the software packages of today that they leave no clear separation of
compilation and configuration. Which makes it, as far as I can tell,
impossible to do a 'minimal build' on the usual, fully compiled binary
packages.


  Well, it can sort of be accomplished with pkgsrc.  Before the configure
step, you'll usually get an on-screen message saying "The following flags
may affect the build of this package; USE_X11", or something similar,
scrolling by.  I think the ports system is better in this regard, with the
menu thingy that some packages gives you.
Yes, but please discern all aspects *strictly*. The configure step you 
write of, is a step *only* applicable to building-processes, not the 
installation of binary packages.

Also, I reminded of the fact that it is a problem of the software 
packages *themselves*. They shouldn't require users to compile-in 
configuration options. So, its not our task, in a way.

 If possible, the package system should be portable.  If not possible,
make it work on DF instead of sacrificing good features.  For "all other
platforms" there's already pkgsrc..


Portability came into my mind today in fact. :)
But define portability... UNIX? Or more?
More might be possible, at least I already thought a bit about it
and see no unovercomable obstacles. But would it be useful?
The packages distributed by systems like pkgsrc are UNIX-only,
as far as I know. And those are the ones we would be primarily
interested in.


  IMHO it would be too hard trying to extend the package system beyond
UNIX-like platforms.  But then if it can be done, why not?  If you have a
clean separation, the dependency handling should be similar across
platforms, even if the building part isn't.
Okay. Then I think we are in accord about this. Just make a technically 
clean architecture, which should enable us to realize this, but not
set it as a goal (for now at least).

 Dependencies.

 There's two sides to this argument, but personally I'd like to see
dependencies being specified only in terms of capability / major versions
/ API revisions.  The other, IMO, is forcing dependencies to be of the
"best" version (for example security-wise).  In my opinion, depending on
specific versions just ties packages tighter together and makes it harder
to replace just a single one, and you'll have a bigger and bigger mess as
the package collection grows.  On the other hand, this shifts more
responsibility to the user having to keep track of which versions work
well..


As a wrote more times: mostly the one thing doesn't exclude the other. :)


  It should.  I'd prefer a strict adherence to one or the other, so that
at least you'll know what to expect.  Preferably minimal dependencies, and
then having security checks separate.  Maybe I'm misunderstanding you
again..
Yes, you are, I suspect. :P

* You think I meant:
Facts:
- Approach 1 -> benefit 1, deficit 1.
- Approach 2 -> benefit 2, deficit 2.
Choose: Approach 1+2 -> benefit 1+2. But, manage in some way to not 
suffer from deficit 1+2.

* You would however like to see:
Facts:
- Approach 1 -> benefit 1, deficit 1.
- Approach 2 -> benefit 2, deficit 2.
Choose: Approach 1 OR 2 -> benefit 1 OR 2. Manage in some way to not 
suffer from deficit 1 OR 2, AND find a way to obtain the other benefit 
(1/2).

* What I *really* mean:
Facts:
- Approach 1 -> benefit 1, deficit 1.
- Approach 2 -> benefit 2, deficit 2.
- Approach 3 -> benefit 1+2, WHY: this solution is not of the same class 
as Approach 1/2.

Choose: Approach 3, IF: it has been fully worked out, and thus its 
theoretical existence is also found practical.

I had a software system in mind that lets users determine this
themselves. This way problems with dependencies can and will be reported
to the authors of the software in question, instead of the 'porters'.
Of course, reasonable predefines should be shipped when requested to...


  Won't work.  Say I'm the author of "SnazzyMusic" (currently at version
1.2.3).  One day comes a report that SnazzyMusic (version 1.1.1) won't
build on ObscureBSD because of a conflict with ClosedSSL.  What should I
do?  Why should I care?  It works just fine on my Linux box, after all.
Misunderstanding again. :D

YOU shouldn't do anything! :)
The ObscureBSD users who experiences the problem you describe should, in 
my solution. What? He could fix it himself, but he probably reports his 
troubles to the software author(s), because the fault must be on their 
side (considering the perfectness of our software system B-)).

Magnus
--
Greetings,
WMD (tfa . x @ inter . nl . net)