Yes this is a good time for some hard thinking. Better time than any. Is there a wiki page with a tentative list of what we are targeting for VyOS 2?
As for the proposal of consolidating -op and -cfg packages, that's not a bad idea to me. I was thinking that this would be bad for potential future collaboration with EdgeOS - however I suspect that using vyconfd will have impact on every module at which point sharing code might be much more difficult? So perhaps this isn't worth bearing in mind. One thing is that having granular packages can be useful for hackers and testers. To try a patch on VyOS 1.1.5, you don't have to build an ISO - you can just build a single package and dpkg -i it. Sure devs might not mind just changing files directly, but this also helps with asking users to try a patch as well. It also means that nightly build packages are more able to be applied into stable builds to test bug fixes since the amount of change is usually limited in scope. The one other place that the granular packages might be good is that some consumers of VyOS might customize packages downstream, and having VyOS in a single (or a few) bigger packages might make for extra work for these groups. That said - it's a hypothetical, I haven't actually spoken with anyone who uses it. Other thoughts? Cheers Patrick On Apr 17, 2015 10:44 PM, "Daniil Baturin" <[email protected]> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > Now we have every bit of functionality in its own git repo which > produces its own debian package. > Many packages are split into -cfg and -op parts. > It's hardly feasible to change it now, but for 2.0 we probably should > think it through. > > Pros: > * Git operations are very fast > * It's easy to read git history of every bit of functionality > * It's easy to update individual packages for testing new changes > > Cons: > * Even if individual package build time is decreased, overall system > build time is increased because every package has its own initialization > and finalization procedures. In tiny packages, autoconf and lintian are > the slowest stages, and we repeat them over 50 times. > * None of (vyatta|vyos)-* packages make sense without all other. > * There are lot of things that are out of place, but it's not obvious > how to fix it in a sane way. vyatta-nat depends on vyatta-cfg-firewall > libraries, but moving those libs into say vyatta-firewall-common and > creating yet another package is hardly a good idea. Interface templates > for features unrelated to quagga are in vyatta-cfg-quagga because it has > a script for copying them to every interface type and no one wanted to > duplicate that script. Examples are many. > * Tracking all packages is substantial effort. Individual package > versions already became meaningless, we often have to check where a file > is from with dpkg -S etc. Repos are big and keeping the "release" repo > in sync with the dev repo is hard and not very automation-friendly. > > Also: > * Since most of our stuff is in /opt/vyatta, it's easy to find out how > big it is. In 1.1.x it's just 13 Mbyte big, > even if it was a single package, its size would be rather modest by > modern standards. > > This makes me think we should keep the number of packages to minimum. > Reusable tools and libraries (e.g. eventwatchd) certainly deserve their > own repos since they can be used outside VyOS. > ISO/AMI/other image format build scripts and the GUI probably should get > their own packages too. > Otherwise I think it should be kept in a single package, or just a few > packages. > > Any thoughts? > > > - -- > #!/usr/bin/env perl > @a=split(//, "daniil @ baturin . org" );# Daniil Baturin > @b=split(//,q/Px%!+o0Q6lh*7dp$.@8#%|y{/);while($i<24){$_.= > chr((ord(@b[$i])-ord(@a[$i])+62)%94+32);$i++};print"$_\n"# > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBAgAGBQJVMRxFAAoJEEcm35UR4K8fF2kP/0ldgZ7WWwyx7Ew5qciperHc > twPr5hO3ASCWXqDei8upVy6OfDE265+4MnO2f16n2HpfOnz3WVtgvA/lXH7yUQFx > 0gaGxqewrBSwwUgW3Cf2pA3Q5U8UZgWANi4pR5cI7yfW1kn7UqTg8G3V7OkNeH/G > 9u5IEgk3ugJscPtPtROmreBCFlSEyThmwRBKjOH6mjvulnc5ueKmwooHrXQNpBgA > yxsIdTv4U8EjXn1+/MVsx5jLz9Bg/ZKLVSQRETSDEwsqxO6rp0VpffLSCH1MYhD5 > sTfai3vIPC5sptVvGFzadD1FrYa2ONzVWZ0w2QJr2KezVHR5vGLbfN11ATgnAkkh > zL/JULwK3RcwNVz71zbGwBeeS+ydViEa4fcfhUlsyRj44WTnxUqsiAXBKOSQZ/g+ > VThYt/XBsZgNIRrwgB3zKm2CCdtxBU5Ot5gUMvp+73fuBh4g6ZTGP3wSVnILmY6C > m1D15Z79kF9c9MOuC3C5OOrPXf7rb1O+WNznw4YkG5oYM7Nwj7gB275znscxQfiF > AJyZQIaF2lNYfbF4ax8ELJtxQvU2kxESaECG0f+BXLnWN3xVXI5UcgktfCrpY90e > WWS7kjj/54PxqM1ObwpKC738bdrmbkDlZVaK69dk2o9i0yvEi+mzD+ckXmfbKpxs > Vv35U7ABlqbHMbycLzUx > =pQqY > -----END PGP SIGNATURE----- > > > > _______________________________________________ > Vyos-developers mailing list > [email protected] > http://lists.tuxis.nl/listinfo/vyos-developers >
_______________________________________________ Vyos-developers mailing list [email protected] http://lists.tuxis.nl/listinfo/vyos-developers
