Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Josh Triplett]

Package: partman-auto
Severity: normal

In all of the recent discussions about separate /usr partitions, most
people seem to acknowledge them as unusual, special-purpose
configurations, even those who use them.  To the extent they have a use
at all, they primarily have a use for people who have very specific
reasons for wanting them, and all of those people will know how to
handle partitioning.  To a lesser extent, that holds true for having
separate partitions for /var, /tmp, or other top-level directories.  It
seems likely that any such setup will have custom requirements.

Meanwhile, we don't want to steer any new users towards a setup with a
pile of different partitions, which makes their system more complex with
more potential failure modes.

In the most recent thread, I noticed that someone mentioned they
primarily chose a setup with a separate /usr partition because the
installer offered such a setup as one of the standard guided
partitioning options.

Please consider removing the option in the guided partitioner for
separate /usr, /var, and /tmp partitions; that would leave only the "All
files in one partition" and "Separate /home partition" setups, both of
which potentially make sense for users of the guided partitioner.
Anyone desiring a setup with more separate partitions should have no
trouble using the manual partitioner to create whatever custom
configuration they desire.

- Josh Triplett



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111215204633.4096.81498.reportbug@leaf

Re: [pkg-wpa-devel] libnl3 soname change

[Stefan Lippers-Hollmann]

Hi

On Thursday 15 December 2011, Joey Hess wrote:
> Heiko Stübner wrote:
> > So the question would be on how to proceed to get this into unstable 
> > without 
> > breaking to much.
[...]

I have prepared and tested (for the non-udeb cases, see below) iw[1] and
wpasupplicant[2] in svn now, likewise hostapd[3] will switch to 
libnl-3 >= 3.2 (from libnl1) after it gets available in unstable (no 
urgency at all). 

Something seems to be missing for the udeb handling though:
Package: wpasupplicant-udeb
[...]
Depends: libc6-udeb (>= 2.13), libcrypto1.0.0-udeb (>= 1.0.0), libnl-3-200-udeb 
(>= 3.2.3), libnl-genl-3-200, busybox-udeb


I'm not overly familiar with udeb specifics, but I think this is 
missing something equivalent to
DEB_DH_MAKESHLIBS_ARGS_libnl-3-200 := -V"libnl-3-200 (>= 
$(DEB_UPSTREAM_VERSION))" --add-udeb=$(udeb)
in libnl3's debian/rules.

We can look for upload sponsoring as needed, at least once the udeb 
issue with wpasupplicant is settled.

> > Another question for the installer folks: should the udeb stay as it is, or 
> > should it be split too.
> 
> d-i only needs it for wpasupplicant, so if that does not need all the
> libraries, some could be dropped from the udeb. Otherwise, I see no
> point of splitting the udeb.
> 
> joey@gnu:~>ldd =wpa_supplicant|grep libnl
>   libnl.so.3 => /usr/lib/libnl.so.3 (0xb7707000)
>   libnl-genl.so.3 => /usr/lib/libnl-genl.so.3 (0xb7702000)
> 
> Perhaps it only needs those 2, but I have not checked closely.

All afforementioned packages only need those two. Additionally I've 
taken a look at crda (disclaimer, I've been involved in the initial 
packaging, but am currently not its maintainer) which would only need
those as well (it's currently still using libnl1); crda is required by 
mac80211 based kernel modules to switch regulatory domains (access 
channel 12-14 or basically any 5 GHz channel) both interactively 
(iw reg set , /etc/default/crda) or 
non-interactively through EEPROM/ OTP regdom hints).


For iw (which is needed by crda's udev rules), it would be nice to 
have libnl.so.3 and libnl-genl.so.3 in /lib/ (#622247: iw binary should
be installed in /sbin). The wpasupplicant package would also profit 
from that (#537790), although it is haunted by openssl and zlib as 
dependencies well.

Regards
Stefan Lippers-Hollmann

[1] Vcs-Svn: svn://anonscm.debian.org/svn/pkg-wpa/iw/trunk/
Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-wpa/iw/trunk/
[2] Vcs-Svn: svn://anonscm.debian.org/svn/pkg-wpa/wpasupplicant/trunk/
Vcs-Browser: 
http://anonscm.debian.org/viewvc/pkg-wpa/wpasupplicant/trunk/
[3] Vcs-Svn: svn://anonscm.debian.org/svn/pkg-wpa/hostapd/trunk/
Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-wpa/hostapd/trunk/


signature.asc
Description: This is a digitally signed message part.

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Marco d'Itri]

On Dec 15, Josh Triplett  wrote:

> Anyone desiring a setup with more separate partitions should have no
> trouble using the manual partitioner to create whatever custom
> configuration they desire.
I agree.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Russ Allbery]

Josh Triplett  writes:

> In all of the recent discussions about separate /usr partitions, most
> people seem to acknowledge them as unusual, special-purpose
> configurations, even those who use them.  To the extent they have a use
> at all, they primarily have a use for people who have very specific
> reasons for wanting them, and all of those people will know how to
> handle partitioning.  To a lesser extent, that holds true for having
> separate partitions for /var, /tmp, or other top-level directories.  It
> seems likely that any such setup will have custom requirements.

I don't think these things are alike.  Separating /var and /tmp from the
rest of the file systems is done because those partitions contain varying
amounts of data and often fill if something goes wrong, but can fill
without impacting the rest of the system and allowing easy recovery if
they're not on the same partition as everything else.

Separating /var continues to be good and recommended practice if you're
running anything that's likely to produce a lot of output, IMO.  (/tmp
should probalby just be tmpfs, but that's another discussion.)

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d3bph1ww@windlord.stanford.edu

Re: daily build 12/12/11 amd64

[Michael Gilbert]

On Tue, Dec 13, 2011 at 9:08 AM, Richard wrote:
> Hi
> I used the daily build 12/12/11 for a clean install on a amd64 machine,
> the network dchp problem is fixed, but the graphical install still freezes on 
> the first page,
>  or could be no response to mouse or keyboard.

Hi, I'm still having trouble understanding exactly where you're trying
to say this problem happens.  But anyway, it would be better to submit
this as a bug against the debian-installer package.  Make sure to
describe exactly the menu items you're selecting (text install,
graphic, expert?), and even describe the screens that do work so we
can get a feel for where this happens.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MPfo2FJ=_jhpawxoa_nbv4-rrqv-zcdli7qdyrwba6...@mail.gmail.com

Debian installer build: failed or old builds

[Daily build aggregator]

Debian installer build overview
---

Failed or old builds:

* OLD BUILD:sparc Dec 13 00:13 buildd@zee build_cdrom 
http://d-i.debian.org/daily-images/sparc/daily/build_cdrom.log

* OLD BUILD:sparc Dec 13 00:17 buildd@zee build_netboot 
http://d-i.debian.org/daily-images/sparc/daily/build_netboot.log

* OLD BUILD:sparc Dec 13 00:20 buildd@zee build_miniiso 
http://d-i.debian.org/daily-images/sparc/daily/build_miniiso.log


Totals: 111 builds (0 failed, 3 old)


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1rbm9b-000513...@ravel.debian.org

Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

[Christian PERRIER]

(reducing CC as I guess that most are subscribed to -devel)

Quoting Russ Allbery (r...@debian.org):

> I don't think these things are alike.  Separating /var and /tmp from the
> rest of the file systems is done because those partitions contain varying
> amounts of data and often fill if something goes wrong, but can fill
> without impacting the rest of the system and allowing easy recovery if
> they're not on the same partition as everything else.
> 
> Separating /var continues to be good and recommended practice if you're
> running anything that's likely to produce a lot of output, IMO.  (/tmp
> should probalby just be tmpfs, but that's another discussion.)

I'm inclined to follow this advice and would indeed propose that the
"atomic" partman-auto recipe is kept, however without a separate /usr
partition (discussions on -devel and the current practice convinced me
that a separate /usr is seomthing that probably belongs to the former
century..:-)


So, would it be OK for participants in this discussion is we, in the
installer, just drop separate /usr but keep the atomic recipe (which
is not the default choice, by the way)?




signature.asc
Description: Digital signature