Re: [dev] [mkpkg] a suckless package manager

Yo

you should check slpm before arguing ;)

i also recommend u to try pkgsrc. Its all done by makefiles. Kinda more complex than mkpkg, but farly better than the gnu build system.

mkpkg should define some vars like WGET HG and others to support other commands..bsd systems does not have wget for example. And use $WGET in the pkg mkfiles.

----- Original message -----
> (Sorry if this appears to be a separate thread. I can't actually
> recieve email right now.)

np. Its ok to discuss it here :)

> > Which means that you have to specify the full compilation rules for
> > every pkg
>
> If by "full compilation rules" you mean "cd $dir && make install". I'm
> sure maintainers will cope. The slpm equivalent package:

yep. Thats something you will have to repeat for each package.

Use 'make' is not good. Make already defines $(MAKE) pointing to $0 which is ok for gmake and others. Your way is just non portable.
 
Not using DESTDIR and PREFIX is just bad for installing out of sandboxes. All packages must honor those vars. Else you cannot track correctly the installed files, find conflicts or detect issues before installing.

Here u trash the system with the building directory which imho should be contained somewhere specified in a global .mk

> > URL=http://hg.suckless.org/dwm
> > TYPE=hg
> > DESC="dynamic window manager"
>
> The only thing different is that instead of using two lines to specify
> the url and type, mkpkg just says "hg clone ...". A bit simpler, I
> think. And makefiles are a standard, whereas slpm packages are not.

What about reusing the same repo and hg pull instead of hg clone everytime? Slpm does this for git,svn and hg.

Slpm packages are just shellscripts. Posix. Which is also standard.

How do you specify userdefined config.h or configure flag options? Letting the user modify the pkg? Imho this must be defined outside in a global mk controlled by the user. Not owned by the pkg system. This way u can rsync the pkgdir without problems.

> > this is also an issue if you plan to use other tools like wget/ftp/..
>
> I'm not sure how this is an issue. Each package states what command to
> use to get the source. If you want to specify a specific method, add a
> new target (this can be in the same file as "dwm", or a separate one,
> it doesn't matter):

yep. Thats good. But you cannot discover which installation methods u have for each package without doing it manually. Which is bad for system maintaining. And its something fun at the begining, but tedious, and make the packages more complex.

In slpm each package have only one retrieving and building way.

> > http.dwm: http.dmenu
> > test -d dwm || wget -O- http://hg.suckless.org/dwm/archive/tip.tar.gz
> > | tar -xz cd dwm && make install
>
> > And imho keeping track of files and having support to remove packages
> > are some basic features of a package manager :)
>
> Like I said, you can add support to uninstall a package:
>
> > rm.dwm:
> > cd dwm && make uninstall
> > rm -fr dwm

this is ok only for src packages that properly implement the uninstall target. Sadly thats not something u can find in all the projects.

> Now "mkpkg rm.dwm" uninstalls the package.
>
> > Now its about 500LOC and supports checksumming of files, dependencies,
> > many more packages, creation of chroot environments by detecting
> > missing libs and supports binary and src packages.
>
> Mine is 8, supports checksumming with hg(1), wget(1), etc, and
> creation of chroot environments with chroot(8). It supports binary and
> source packages, since you can define any target and any commands
> whatsoever (again, same file or not):

yeah. 8 sloc is a good marketing label.

I probably missexplained the what chrooting is. Mkpkg does not supports chroots for many reasons:

* not using destdir or prefix in any way, dwm would work, but programs pointing to external files will fail
* not installing any library dependency from anywhere, so just having the binary will just not work unless u do it statically.
* No ld-linux copied or base filesystem hirearchy created. So it will not boot.

In slpm the user can use chroot happily, slpm is not replacing it in any way. It just build the things in the correct way.

> > bin.dwm
> > wget <url of binary>
>
> Why does slpm have to be such an "all-in-one" solution? We already
> have a system for detecting dependencies, tools to fetch any given
> url, and a tool to build and install a given program. We don't need to
> reinvent wheels. The great thing about Unix is we can just glue these
> parts together.

Slpm started as a toy, and it growed so much, actually i plan to refactorize it. You can pipe many outputs of slpm in order to extend the features of it.

Slpm keep track of files and checksums of each file installed in destdir, so you can determine whats there and properly remove, upgrade or check for changes. You cant do this with mkpkg. And thats somewhat basic for a package manager. Else what you do is a build assistant.

> cls

clear
Received on Sat Aug 14 2010 - 16:55:50 CEST