[Slapt-get-devel] slapt-src utility in need of early testing

[Jason Woodward]

Hi Igor,

> I'm glad you started to develop slapt-src. )
> 
> 
> Here is my suggestions:
> Almost all SlackBuilds that I've seen allow to set ARCH from the outside.

> It 
> will be cool if slapt-src will allow to set ARCH too. I don't have any
> reason 
> to build packages with default i486 arch. I'd like to build packages for
> i686 
> or even with '-march=native -mtune=native'. Altering build suffix will be

> cool 
> too.

I can probably have that honor an existing environment variable and/or let
you specify the defaults in the slapt-getrc file.

> For testing purpose I propose to use '-s' switch just as '--simulate|-s'
to
> be 
> able to see what will happen without worrying that something unexpected
> will occur.

Something like that may happen later in the design/development phase. 
Right now there is no transactional behavior at all.

> Anyway '-s' is broken at the moment:
> ------------------------------------
> # slapt-src -s clive
> slapt-src: option '-s' is ambiguous

Thanks, just pushed a commit to fix that.

> Some bugs:
> Man page and slapt-srcrc not installed by  'make install'.
> "[  --update|-u  ]" mentioned twice in SYNOPSIS section of man
> page.
> Short options broken (-s and -w) because of getopt_long_only().

Thanks again, just pushed commits for those.
 
> Some questions:
> How slapt-src handle dependencies? 

That is still to be done.  It seems like a build depends and runtime
depends should be declared for each package (as an extension to the current
SLACKBUILDS.TXT format).  

The only fuzzy part for me is how slapt-src could leverage slapt-get for
both the runtime and build time dependencies.  

So for the --install target (or installing a dependency required for a
--build target), we can check our current know slackbuild list and if
nothing found try to use libslapt to see if we can fetch an available
version.  Or we can just fail and mention the user/admin needs to install
the required packages not currently found in the slackbuilds list.  I would
like to keep it simple so the fail with error and let user decide is
probably going to win out, at least initially.	The same sort of thing
would have to happen for the build dependencies (packages that need to be
installed in order to build the slackbuild, not install it).  Since both
lists can differ the distinction is important.	

> Why slapt-get and slapt-src list info about packages in different
formats? 

One uses PACKAGES.TXT for binary slackware packages and one uses
SLACKBUILDS.TXT for source slackbuild scripts... the later isn't a real
format yet.  I am intentionally keeping the two utilities separate.  I
don't know what the final format or output will look like yet.	Suggestions
welcome!


--
Jason Woodward
<woodwardj at jaos.org>