[prev in list] [next in list] [prev in thread] [next in thread] 

List:       crux
Subject:    Re: Do we need a new package utility?
From:       Johannes Winkelmann <jw () tks6 ! net>
Date:       2002-06-21 7:33:31
[Download RAW message or body]

On Thu, Jun 20, 2002 at 15:25:47 -0300, Mike MacLeod wrote:
> Jahannes
mmmh... :-)

> [...] rather then having it ask us all the time. 
> When I'm about to compile glibc, xfree86, 
> or some other large compilation, I like to just enter a command and go 
> have a milkshake and enjoy a walk. Even if it only asks these questions 
> right away [...]
yep, it's more consistent to not have a user interaction here. a
--dry-run and --install-suggested-packages-as-well (names are most
likely to change) are the solution then 

>    I like your 'rollback' idea, and think it should definetly be part 
> of any new utility that we build.
For a first solution, it will probably just print out: "Build of kdebase
failed. Packages installed already: qt3, kdelibs, libjpg..."
So you can easily remove them. Or it should probably pkgrm them anyway
(as we'll still have the pkg.tar.gz). This will be easy to decide if we
only have a working tool.

>    The reason I said that the pkgfiles should list all the dependencies 
> is because 
Not sure if I get you right here: I also want them in the Pkgfile, but
in a comment, not a bash array. A lot of them are already there, you see
this if you only try 
[winkj@magellan winkj]$ prt-get info kdelibs
Name:        kdelibs
Version:     3.0.1
Description: KDE Librarys.
Dependecies: qt,arts,libxml2,libjpeg,libpng
[winkj@magellan winkj]$ 

> [dependencies should be allowed to packages from base/opt as well]
They will be. But prt-get as I'm going to implement it will never know
where a package is (whether it's in /usr/ports/{base,opt,contrib,...}).
But I find a clean solution IMO to implement this (you'll just have to
specify the directories where to look for packages. This will solve the
'ports too specific for unofficial'-problem as well, as you can specify
'/usr/ports/people/ports-jw' there, and I can the provide a tar.gz
adding this additional tree. You can just depend on any package from
your ports tree).

>    I don't know the details of your repository system, but I think that 
> we should work with the current ports tree in CRUX. 
I though a lot about this, and finally came to a conclusion that this
can be done nicely, but it will enforce the user to always have the
whole unofficial ports tree installed. I guess this is not too much to
ask. (and if you won't do this, you'll simply get an error saying:
couldn't find port: <name>).

> The issue 
> of ports that are too specific for the unofficial tree is something that 
> I don't think the new utility (at least the one I have in mind) should 
> solve.
Well, if you write it, it won't, if I write it, it will.

>    I think it's just a bit early to get rid of the ports tree, because 
> this means that users are limited to whichever repository they decide to 
> use as the base for their system, which removes some (or all) of the 
> flexibility of CRUX that makes it great (at least if I understand what 
> you mean by your repositories).
well, my "repository" can easily be build from /usr/ports, so this is
not a problem. But: I'm going to drop this idea and use the local
directories. 


>    I think that requiring users to have python installed would also be 
> detrimental to the flexibility and functionality of the utility.
(*looking up detrimental*)
I think that using the wrong language would be detrimental for the
development, and negative for the flexibility and functionality of the
utility. Building and resolving a dependency tree in bash is something I
wouldn't know how to do in a clean and maintainable way, as it can be
done in python.
If a user is not willing to run a simple pkgmk -d -i python (even though
I had to tweak it as gdbm wouldn't compile here), I'm wondering what
should make me invest time to write a tool (provide a service) to them. 

I could probably port it to C++ when the _prototype_ is ok. (Saying
that, I might as well stop development if people don't show any
interest or don't value the work).


Conclusion: I have some ideas for a new prt-get. It will start to do
what you want, and remove the negative points you have (it'll use the
regular package tree). I'm not going to promise and functionality after
the weekend, but we'll see. Feel free to join #crux on openprojects.net
get an idea what I'm planning to do.

Regards Johannes
-- 
Johannes Winkelmann         mailto:jw@tks6.net
Trondheim, Norway           http://jw.tks6.net 

[prev in list] [next in list] [prev in thread] [next in thread]