headers
Charles Plessy | 1 Feb 2009 02:16
Picon
Favicon

Re: Test suites after build and Build-Depends.

Le Sat, Jan 31, 2009 at 10:15:15AM +0100, Raphael Hertzog a écrit :
> 
> Note that this decision has been taken because:
> - dpkg-source has never used debian/substvars as input and did nothing
>   unless you gave the -T option

> I hope my answer clarifies the situation. Given that it has not been used
> in 14 years, and that we had no wishlist bug in that direction, it seems
> pretty clear that it's useless and that there are other better ways to
> achieve similar functionnality.

Le Sat, Jan 31, 2009 at 12:10:18PM +0000, Roger Leigh a écrit :
> 
> The .dsc file is exactly where the information is read from.  See
> fetch_source_files() in Sbuild/Build.pm.  This is for installing
> and removing build-dependencies and build-conflicts, respectively.
> Note that dpkg-buildpackage and other tools read debian/control
> to check that the build-deps are satisfied in addition.

Thank you all for your answers,

from my biologist point of view, I find interesting to observe how an unused
function progressively becomes impracticable as the whole system evolves
without pressure to stay compatible with it :) Helper tools such as
mk-build-dep have not been mentionned in this thread, but would also break with
packages containing a substvar in debian/control.

I can try prepare a patch for the Policy if you are interested.

Have a nice Sunday,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Russ Allbery | 1 Feb 2009 02:42
Picon
Favicon

Re: Test suites after build and Build-Depends.

Charles Plessy <plessy <at> debian.org> writes:

> I can try prepare a patch for the Policy if you are interested.

That would be great here.  The current text doesn't reflect reality, so
unless we're going to change reality (for which there doesn't appear to be
much of a consensus), we should change Policy.

--

-- 
Russ Allbery (rra <at> debian.org)               <http://www.eyrie.org/~eagle/>
Permalink | Reply | 0 comments |
headers
Andrew Deason | 1 Feb 2009 02:56
Picon

Re: Release Candidate 2 of Debian Installer

On Sun, 01 Feb 2009 00:19:33 +0100
Bernd Eckenfels <ecki <at> lina.inka.de> wrote:

> In article <87bptnccj6.fsf <at> mid.deneb.enyo.de> you wrote:
> > What needs to be done so that these two issues can be fixed?
> > 
> > | Disk devices may change on reboot
> 
> A good option would be to use LABEL or UID instead.

I believe this still doesn't solve the problem in the case of lilo.conf
or grub's device.map, when specifying e.g. where to write the MBR. Is
there any way around that?

> However I am not sure if that has some drawbacks as well:
> 
> - for uuid the system is less forgiving if you swap disks
> - for label the system is less forgiving if you bring in temp. new
> disks

Label names could be generated to minimize collisions.  Something like
${hostname}-/ instead of /, or maybe something even more specific.

--

-- 
Andrew Deason
adeason2 <at> uiuc.edu
Permalink | Reply | 3 comments |
headers
The Fungi | 1 Feb 2009 04:46
Favicon
Gravatar

Re: Release Candidate 2 of Debian Installer

On Sat, Jan 31, 2009 at 07:56:01PM -0600, Andrew Deason wrote:
[...]
> Label names could be generated to minimize collisions.  Something like
> ${hostname}-/ instead of /, or maybe something even more specific.
[...]

The namespace here is, unfortunately, pretty limited. The manpages
for mkreiserfs and mke2fs mention a 16-character limit for
filesystem labels, so you'd be out of luck trying to (for example)
represent /usr/local in the scheme above without truncating the
hostname to 5 characters. You can't fully represent a mount path
greater than 16 characters in a filesystem label even unprefixed.
Maybe a 14-byte hash of the hostname and path (or even just a
14-byte pseudo-random number, for that matter) represented in 7-bit
ASCII characters would achieve the desired goal? That'd look pretty
ugly though...
--

-- 
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fungi <at> yuggoth.org); IRC(fungi <at> irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fungi <at> yuggoth.org);
MUD(fungi <at> katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
Permalink | Reply | 1 comment |
headers
Arthur de Jong | 1 Feb 2009 10:09
Picon
Favicon

Re: Release Candidate 2 of Debian Installer

On Sun, 2009-02-01 at 03:46 +0000, The Fungi wrote:
> On Sat, Jan 31, 2009 at 07:56:01PM -0600, Andrew Deason wrote:
> > Label names could be generated to minimize collisions.  Something like
> > ${hostname}-/ instead of /, or maybe something even more specific.
> 
> The namespace here is, unfortunately, pretty limited. The manpages
> for mkreiserfs and mke2fs mention a 16-character limit for
> filesystem labels [...]

Also using slashes in labels causes problems with the symlinks showing
up in /dev/disk/by-label.

--

-- 
-- arthur - adejong <at> debian.org - http://people.debian.org/~adejong --
Permalink | Reply | 0 comments |
headers
William Pitcock | 1 Feb 2009 10:22
Picon

Re: Release Candidate 2 of Debian Installer

On Sun, 2009-02-01 at 00:19 +0100, Bernd Eckenfels wrote:
> In article <87bptnccj6.fsf <at> mid.deneb.enyo.de> you wrote:
> > What needs to be done so that these two issues can be fixed?
> > 
> > | Disk devices may change on reboot
> 
> A good option would be to use LABEL or UID instead. However I am not sure if that has some drawbacks as well:
> 
> - for uuid the system is less forgiving if you swap disks
> - for label the system is less forgiving if you bring in temp. new disks
> 
> So I think UUID has less risks.

Anaconda uses LABEL. I don't know the full rationale on why this is, but
it may be a good idea to follow suit.

William
Permalink | Reply | 8 comments |
headers
Mike Hommey | 1 Feb 2009 10:46

Re: Release Candidate 2 of Debian Installer

On Sun, Feb 01, 2009 at 03:22:07AM -0600, William Pitcock wrote:
> On Sun, 2009-02-01 at 00:19 +0100, Bernd Eckenfels wrote:
> > In article <87bptnccj6.fsf <at> mid.deneb.enyo.de> you wrote:
> > > What needs to be done so that these two issues can be fixed?
> > > 
> > > | Disk devices may change on reboot
> > 
> > A good option would be to use LABEL or UID instead. However I am not sure if that has some drawbacks as well:
> > 
> > - for uuid the system is less forgiving if you swap disks
> > - for label the system is less forgiving if you bring in temp. new disks
> > 
> > So I think UUID has less risks.
> 
> Anaconda uses LABEL. I don't know the full rationale on why this is, but
> it may be a good idea to follow suit.

And thanks to that, it's a PITA to have several RH/Fedora installs on the
same computer.

Mike
Permalink | Reply | 7 comments |
headers
William Pitcock | 1 Feb 2009 11:13
Picon

Re: Release Candidate 2 of Debian Installer

On Sun, 2009-02-01 at 10:46 +0100, Mike Hommey wrote:
> On Sun, Feb 01, 2009 at 03:22:07AM -0600, William Pitcock wrote:
> > On Sun, 2009-02-01 at 00:19 +0100, Bernd Eckenfels wrote:
> > > In article <87bptnccj6.fsf <at> mid.deneb.enyo.de> you wrote:
> > > > What needs to be done so that these two issues can be fixed?
> > > > 
> > > > | Disk devices may change on reboot
> > > 
> > > A good option would be to use LABEL or UID instead. However I am not sure if that has some drawbacks as well:
> > > 
> > > - for uuid the system is less forgiving if you swap disks
> > > - for label the system is less forgiving if you bring in temp. new disks
> > > 
> > > So I think UUID has less risks.
> > 
> > Anaconda uses LABEL. I don't know the full rationale on why this is, but
> > it may be a good idea to follow suit.
> 
> And thanks to that, it's a PITA to have several RH/Fedora installs on the
> same computer.

Yes, I could indeed see why this would be problematic. So, UUID might
indeed be a better solution.

William
Permalink | Reply | 0 comments |
headers
Florian Weimer | 1 Feb 2009 11:43
Picon

Re: Release Candidate 2 of Debian Installer

* Andrew Deason:

> I believe this still doesn't solve the problem in the case of lilo.conf
> or grub's device.map, when specifying e.g. where to write the MBR. Is
> there any way around that?

The boot loaders would obviously have to scan for UUIDs, which carries
its own risks (like lockup during boot because the wrong device is
touched).  If the expected location is checked first, this could be
minimized, though.

>> However I am not sure if that has some drawbacks as well:
>> 
>> - for uuid the system is less forgiving if you swap disks
>> - for label the system is less forgiving if you bring in temp. new
>> disks
>
> Label names could be generated to minimize collisions.  Something like
> ${hostname}-/ instead of /, or maybe something even more specific.

The host name is often "debian" at installation time, so I doubt this
would work.
Permalink | Reply | 0 comments |
headers
Christian Perrier | 1 Feb 2009 12:17
Picon
Favicon
Gravatar

Re: Release Candidate 2 of Debian Installer

Quoting Florian Weimer (fw <at> deneb.enyo.de):
> * Otavio Salvador:
> 
> > See the errata[2] for details and a full list of known issues.
> 
> What needs to be done so that these two issues can be fixed?

This has been discussed numerous times in -boot but among the low number of
ppl working on D-I during the etch->lenny release cycle....nobody
cared enough to work on this and solve it out.

http://wiki.debian.org/DebianInstaller/LennyGoals listed that goal and
#389881 has most of the information.

The Squeeze Goals list mentions it again and, here, Colin Watson
stepped up to work on it.
Permalink | Reply | 0 comments |

Gmane