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

Re: vlan support en* or br*?



Hello again.

On Wed, Jan 06, 2016 at 07:27:00PM +0000, Ben Hutchings wrote:
> On Wed, 2016-01-06 at 19:40 +0100, Andreas Henriksson wrote:
> > Hello.
> > 
> > Since this isn't the first time the vlan package with its deprecated
> > vconfig command causes discussions I've gone ahead and uploaded
> > a new version of the package to experimental. See vlan 2.0 also
> > available from https://people.debian.org/~ah/vlan-2.0/ for the
> > impatient who doesn't want to wait for archive updates and mirror syncs.
> [...]
> 
> Nice, but you still kept vconfig's name restriction.  Could you please
> also change the ifupdown scripts to work with any device name so long
> as vlan-id and vlan-raw-device are specified?

Thanks for having a look at this. Please let me elaborate....

I personally don't see a point in the vlan package. I've already
suggested it should be removed. The only reason to keep it I can agree
with is that we still don't give users a better (automated) upgrade
path. For new installs I see absolutely no point in using it at all.
Obviously not everyone agrees on this and that's why I wanted to atleast
get rid of the ioctl based vconfig which noone argues is still needed.

The reason I don't think the ifupdown integration provided by vlan
package is needed is because ifupdown itself provides vlan configuration
possibilities these days. From what I can tell from the manual ifupdowns
vlan support should support whatever name you give your underlying
(real) interface ("foo"). It only forces you to use a period (.) in the
name (eg. "foo.123" for vlan id 123, while vconfig had several possible
naming schemes for no apparent reason).
Thus if you don't like the limitations of the vlan packages ifupdown
integration, just use the built-in functionality of ifupdown instead!
For anyone interested in this please see the interfaces(5) man page
and look at the "VLAN AND BRIDGE INTERFACES" chapter.

I'm not a user of either ifupdown nor vlan packages myself. I'm not
going to work on extending the vlan package features. I still maintain
that it would be better to remove it as my personal opinion, but given
that there are apparent people who still find it useful to install it I
think it's useful to atleast get rid of the worst parts of the vlan
package.

And as mentioned in the previous mail, the updated version retains all
limitations of the previous package. If someone finds it useful to
extend it feel free to do so, but I people to please investigate your
options before wasting your time.

Suggestions for what to put in the package description to make it
more obvious for users what to expect are welcome!
(Please make sure to atleast CC me. Mails that do not appear in my inbox
have a high chance of not being read by me.)

Regards,
Andreas Henriksson

(PS. Now if we could only replace net-tools with a similar wrapper
script and finally deprecate the ioctl based tools there as well. ;P)


Reply to: