Re: Vanillux live iso
Hi Ben,
So i wasn't home when i sent my last reply had to quote Google on the man page.
> Please check which version you got that excerpt from.
I was told the reason why live-build was ignoring --mirror-chroot when
i asked why live-build was not using the url passed as parametter.
here is the answer i got:
>>>> it still tryes to pull from debian.
>>>
>>> this is because you have not set --mode, which means it remains default
>>> (=debian) which doesn't make use of derivatives handling.
So if some of the options such as
--mirror-chroot URL
sets the location of the debian package mirror that will be used to
fetch the packages of the derivative in order to build the live
system. By default, this is set to the value of --mirror-bootstrap.
Need to either call --mode progress (for most users that wont mean
anything) or modify the source default.sh (not documented anywhere to
my knowledge) to work. But this isn't clear, for most people outside
the live-build project a Debian derivative is more or less any distro
using the apt packaging system.
To clarify i would suggest changing the man page to something like
--mirror-chroot URL
In derivative mode, sets the location of the debian package mirror
that will be used to fetch the packages of the derivative in order
to build the live system. By default, this is set to the value of
--mirror-bootstrap.
So i just put the derivative mode to false again and --mirror-chroot
is no longer noticed. So without --mirror-chroot URL a "distribution"
has no way to add custom packages using a different
codename/repository than the parent.
I will now revert to a21 but i believe i was having the same issues.
With derivative mode on i get d-i errors because it skips d-i-mirrors
parameters (--parent-mirror-debian-installer &&
--mirror-debian-installer), without i get "E: Unable to locate package
vanillux-desktop" because its skipping --mirror-chroot.
Im going to work on copying vmlinuz not that i learned reprepro cant
pull it automatically with the packages as well as roll back
live-build and do some tests.
It seams to me like the derivative mode is complicating and limiting
things a lot both on the user side and the developer side and to be
honest i dont see why you need it because with simple input validation
you could know if its a derivative/vanilla debian/distribution. Also i
dont see why you disable features in/out of the derivative mode
because some users might need those features (and the features are not
truly disabled but given an unchangeable default value).
I will look at your code tomorrow to see what i can do, i need some sleep :).
On Mon, Aug 15, 2011 at 5:20 AM, Ben Armstrong
<synrg@sanctuary.nslug.ns.ca> wrote:
> On 15/08/11 05:11 AM, Fabrice Quenneville wrote:
>>> ftr: you said you're doing a derivative (in lb terms) for which you need
>>> 3.x, it only got revealed later that you're actually doing a
>>> distribution (in lb terms) for which you don't necessarily need 3.x.
>> Hmmm i never said i was a derivative actually i just posted my configs
>> and the error mesages and you said
>
> Perhaps I was mistaken about your needs, in that case, as I at first
> thought derivatives mode was what you were after, since you appeared to
> be one. I did not understand at that point that it was not really
> suitable in the case where your derivatives model is not live-build's
> derivatives model (which is Debian as a main repo *plus* the
> derivative's extra repos, rather than the derivative wholly replacing
> the repo, which is supported with --mode as in Ubuntu's case).
>
>>>> so i am wondering what im doing wrong.
>>>
>>> if you use derivatives mode, you should make sure you're using lb
>>> 3.0~a26-1 or newer.
>> I had never heard of the derivative mode before and was using a21
>
> Daniel did not tell you to use derivatives mode. He said *if* you use
> derivatives mode, use a26 or newer. I believe I was the first to point
> out that 3.x has a derivatives and wondered if that would be a good fit
> for you.
>
>>>> And as a programmer it makes no sense if you break existing features
>>>> or modify their behavior.
>>>
>>> there are no existing features broken; there are no features modified in
>>> their behaviour (except for syntax changes in config/*, but that surely
>>> was not wat you ment).
>> the man pages sais:
>> --mirror-chroot URL
>> sets the location of the Debian package mirror that will be used to
>> fetch the packages in order to build the live system. By default, this
>> is set to the value of --mirror-bootstrap.
>
> The man page of which version? In a26 and a29 there is:
>
> --mirror-chroot URL
> sets the location of the debian package mirror that will be used
> to fetch the packages of the derivative in order to build the live
> system. By default, this is set to the value of --mirror-bootstrap.
>
> Seems clear to me.
>
>> but in fact that feature is disabled unless in derivative mode, that
>> feature is not working as it should as per the man page.
>
> Please check which version you got that excerpt from.
>
>> You told me
>> so in your 3rd response:
>>>> it still tryes to pull from debian.
>>>
>>> this is because you have not set --mode, which means it remains default
>>> (=debian) which doesn't make use of derivatives handling.
>
> Historically, --mode changed the major mode of operation for numerous
> things for a project such as ubuntu or emdebian that does not adhere to
> the Debian repo + additional repository model. Supporting such
> derivatives had quite a bit of extra overhead to handle each case, as
> such derivatives diverge so much from Debian that we cannot know exactly
> what they contain. Therefore, it has always been necessary that at least
> one person who both knows their own derivative intimately and knows
> live-build code intimately provides us with a stream of patches to
> continue to support their mode to keep up support for it. As you can
> see, that's not an easily sustainable model.
>
> As I understand it, the new support is for a lighter weight alternative
> model for derivatives, having most packages taken from Debian and
> additional packages from the derivatives repo. This "Debian plus" model
> of a derivative is much easier to support because it is essentially
> Debian with few changes to packages concentrated in the additional
> packages that derivative provides.
>
> Your model seems to be something that is not quite one and not quite the
> other. You're not a "full derivative" (for lack of a better term) which
> completely branches from Debian, replicating all our infrastructure
> (including people within your project who intimately know live-build and
> provide us with patches). Nor are you a "Debian plus" derivative, which
> would be a lot easier to support.
>
>>>> Take your time to code all of that, not to
>>>> be able to leave a simple note in the man page for the users like
>>>
>>> for the love of god.. the package itself is in *experimental*..
>>> *experimental*.. *experimental*..
>> How does that justify not documenting your development process in the
>> man if all it needs is a few words to save users hours if not days of
>> debugging.
>
> Clearly it doesn't need "a few words", as no amount of words so far have
> led us to a satisfactory solution, especially since we're not even
> consulting the same versions of the man page.
>
> I haven't the time before I head out to work to address each additional
> point of your email point by point, but until we're at least discussing
> the same man page version, I am not sure what the point of it would be.
>
> Ben
>
--
Fabrice Quenneville
fabrice@vanillux.org
Reply to: