[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: installer location on mirrors

On 12851 March 1977, Joey Hess wrote:

>> I don't think the installer images should be in dists/ as they are now,
>> but get their own location, installer/. For various reasons, including
>> the - wth was it added there in the first place, - currently an
>> installer update move from one suite to another means real
>> copies/moves. Why, pool/ got rid of that for our packages, why do we
>> have it for the installer? Also, its really big and doesn't belong into
>> dists/, which is more like a set of "Package indices".
> It seems like pool/main/d/debian-installer/$ARCH/$version would be a
> good place to put it. Unless having non-debs in pool would break
> something's assumptions.

Yeah, at least one dak tool does. check_archive, comparing pool/ with
what is in the database. I have no idea if anything external does so
too. Also it would introduce things into pool/ that aren't in any
"index", AKA packages/sources. Don't know what tools like
debmirror/reprepro would say about that. Though, debmirror probably just
ignores it.

> If it's in pool, then dists could just link to the right one, ie:
> dists/sid/main/installer-i386/current -> ../../../../pool/main/d/debian-installer/i386/20120508

> I think this preserves backwards compatability in a clean way that
> won't need further work later, while meeting your goals.

We can do the same thing putting it in installer/, i think.

>>              wheezy -> 20120508
>> There is one drawback I see outright - we no longer have a "current"
>> link. I might miss something here, but is the current link really
>> required, if we build it up like the above?
> What if a user is installing stable and cannot remember the release code
> name? (Not hypothetical; I couldn't tell you the current release
> codename offhand.) The advantage of keeping the symlink in dists is that
> it's right there with the other files for whatever dist the user
> navigates to. Also it avoids special cases.

I wonder which special cases, but I won't object to keep the current
symlink. Compared to what we have now, thats small. :)

So to rephrase my proposal:

- dists/*/main/installer-$arch content moves to installer/$arch/
- dists/*/main/installer-$arch/current will be a symlink into
  installer/$arch/, pointing to the latest for that suite
- "Updating" the installer from one version to another (like, point
  release time) is a simple change of the current symlink.
- additionally we have the $release -> $version links as described in my
  first mail, for people that go directly into installer/ (and can
  remember the codenames :) ).

I also take it we don't need/want the main/contrib/non-free in
installer/, as our d-i will always be main/ only.

I understand it right that doing it this way (ie. current symlink stays
around), it won't break anything, so we can "just do it for all suites"?!

bye, Joerg
Getting out of jury duty is easy. The trick is to say you're prejudiced
against all races.

Reply to: